X.500 system and methods

ABSTRACT

The present invention addresses the problem of implementing X.500 using an SQL product. The present application discloses an application of X.500 to a relational database, a database design and use of the database to perform X.500 services. Particularly, the disclosure relates to implementation using an RDBMS (Relational DataBase Management System). One invention disclosed resides around service modelling, the processing of arbitrary data using a fixed set of queries/services. Another invention resides in the implementation of a disk based model using relational queries to satisfy X.500 services and enables benefits of RDBMS to be exploited. Further, the invention provides an SQL based X.500 application that can perform at subsecond speed and is relatively unaffected by the size of database, DIT shape, type of data or complexity of service, including aliases.

FIELD

The present invention is directed to application of X.500 to arelational database, a database design and use of the database toperform X.500 services. Particularly, the present invention is directedto implementation using a RDBMS (Relational Database Management System).The present invention is also directed to table structure and method ofoperation of a database application.

PRIOR ART

X.500 is the International Standard for Electronic Directories[CCITT89]. These standards define the services, protocols andinformation model of a very flexible and general purpose directory.X.500 is applicable to information systems where the data is fairlystatic (e.g. telephone directory) but may need to be distributed (e.g.across organisations or countries), extensible (e.g. store names,addresses, job titles, devices etc.), object oriented (i.e. to enforcerules on the data) and/or accessed remotely.

Relational Database Management System

(RDBMS) provide facilities for applications to store and manipulatedata. Amongst the many features that they offer are data integrity,consistency, concurrency, indexing mechanisms, query optimisation,recovery, roll-back, security. They also provide many tools forperformance tuning, import/export, backup, auditing and applicationdevelopment.

RDBMS are the preferred choice of most large scale managers of data.They are readily available and known to be reliable and contain manyuseful management tools. There is a large base of RDBMS installationsand therefore a large amount of existing expertise and investment inpeople and procedures to run these systems, and so data managers arelooking to use this when acquiring new systems. Most relational databaseproducts support the industry standard SQL (Structured Query Language).

There has also been a move towards a move towards Object Orientedsystems which provide data extensibility and the ability to handlearbitrarily complex data items. In addition, many corporations andgovernment departments have large numbers of database applications whichare not interconnected. Data managers are looking for solutions whichenable them to integrate their data, and to simplify the management ofthat data. X.500 and it's associated standards provide a framework and adegree of functionality that enables this to be achieved. The fact thatX.500 is an international standard means that data connectivity can beachieved across corporations and between different countries.

The problem, therefore, is to address the need of data managers andimplement X.500 with all the flexibility of object-oriented systems butusing an SQL product so that it can achieve the scalibility andperformance inherent in relational systems coupled with the stability,robustness, portability and cost-effectiveness of current SQL products.

There have been a number of attempts of solving the above problem andover a considerable period of time. None of the attempts have resultedin a product which has proven to be commercially accepted by the market,and thus in the market place there is a long felt need yet to beaddressed.

FIG. 1 shows an abstract from the "GOSPINews" issue No. 4, dated April1994 (Source: "Interoperability Products" distributed in Australia bythe Centre for Open Systems) and which lists X.500 products currentlyavailable. None of these products use a SQL database as an underlyingdata store, and none of these products therefore address successfullythe market need of implementing X.500 using an SQL RDBMS.

The Proceedings of IFIP WG6.6 International Symposium (ISBN: 0444 889167) have published a paper presented by Francois Perruchond, Cuno Lanz,and Bernard Plattner and entitled "A Relational Data Base Design for anX.500 Directory System Agent". The Directory System disclosed, as withmany prior art systems, is relatively slow in operation, particularlywhere the database is relatively extensive and is incomplete in itsimplementation of X.500, such as aliases, subsearch and entryinformation.

Another attempt is disclosed in the proceedings of IREE, ISBN 0909 394253, proceedings Apr. 22-24, 1991 by C. M. R. Leung. In that disclosure,there is described a database scheme in which a single entry table holdsdetailed information about each directory object, and is also incompletein its implementation of X.500.

This approach has been discredited by a number of text books andknowledge in the art, such as "Object-Oriented Modeling and Design" byJ. Rumbaugh, et al, 1991, ISBN 0-13-630054-5, in which at paragraph17.3.8 it is clearly stated that "putting all entities in one table isnot a good approach to relational database design".

SUMMARY OF INVENTIONS

An object of the present inventions is to address the problem ofimplementing X.500 in a RDBMS which supports SQL or any other relationallanguage.

The present application seeks to disclose a number of inventions relatedto the implementation of X.500 services in a RDBMS which supports SQL orany other relational language. X.500 services can be invoked via anumber of protocols, such as X.500 and LDAP.

The scope of the present invention is outlined in this specification,including the claims.

In this document, at the time of filing, SQL is the most popularrelational language and although it is only one form of relationallanguage, the intent of the present invention is to have application toany other form of relational language, not just SQL.

These inventions can be related to the following headings:

1. Principle Design

2. Conceptual Design

3. Conceptual Method(s)

4. Logical Design

5. Logical Method(s)

6. Physical Design

7. Example Implementation

The X.500 standard in no way dictates how the directory is to beimplemented, only its capabilities and behaviour. One key to solving theimplementation problem is the realization that X.500 defines a fixed setof services (e.g. Add, Modify, Search etc.) that can operate onarbitrary data.

It has been discovered that problems associated with the prior art maybe alleviated by a unique approach, by what may be described asinverting relational theory modelling from a data modelling approach toa service modelling approach. That is, from the problem of:

processing arbitrary queries on a fixed set of data to the presentapproach of processing arbitrary data using a fixed set ofqueries/services.

Each service is modelled (instead of each data type) and therelationships between each service defined (instead of the relationshipsbetween each data type).

Implementation of service modelling using relational queries to satisfyX.500 services enables benefits of RDBMS to be exploited.

The benefits of this approach are many. A summary is illustrated in FIG.3. Some of the benefits include:

relatively fast starting time.

the ability to reduce memory requirements relative to memory residentsystems.

the ability to base X.500 on any SQL database and thereby protect theinvestment in products, expertise and procedures in managing existingsystems.

the ability to achieve performance relatively independent of size andrelatively independent of the complexity of the data type. Every datatype is treated generically. Every data type has an index on it. Theresult of indexing gives the ability to efficiently search the directorywithout caching large portions of directory into memory. Unlike theprior art where either only one index can be used to satisfy one givenquery or large portions of information is system intensively cached andsearched in memory.

the ability to support different languages (e.g. Spanish, Hebrew andKanji) which may have various collating sequences. Single, double orother byte character sets may also be supported.

using a disk based model to minimise I/O and efficiently retrieve I/O.

the ability to service complex X.500 searches.

the ability to create X.500 databases of far greater size thanpreviously possible, without compromising performance or robustness. Thedatabases can be small or large (250,000, 1 million or more entries).

an optimal table design minimises wastage of disk space.

the ability to leverage off hundreds of man years of relational databasedevelopments and use "industrial strength" databases with provenreliability, integrity, security and tools for developing highperformance applications.

Based on this unique approach, the following disclosure will detail anumber of inventions in an order with reference to FIGS. 2A and 2B,which illustrates schematically an overview of the present X.500 system.The table and column, names, order of columns and numeric valuesdisclosed are given on an arbitrary basis in the overview. The number ofcolumns disclosed represent a preferred operable requirement. Additionalcolumns do not alter the use of the table as herein contemplated.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a table which lists X.500 productscurrently available, none of which use a SQL data base as an underlyingdata store.

FIG. 2A is an illustration schematically of an overview of the presentinvention, particularly the principal design and the correspondingconceptual design, as applied to the provision of a table structure foran X.500 system.

FIG. 2B is an illustration schematically of an overview of the presentinvention, particularly the logical design and the correspondingphysical design, as applied to the provision of a table structure for anX.500 system.

FIG. 3 is an illustration of a pie chart that provides a summaryrepresentation of the benefits of implementing service modeling usingrelational queries to satisfy X.500 services.

FIG. 4 is an illustration of a hierarchy within a hypotheticalorganization, arranged as a tree, that is used to explain the servicesthat may be provided according to the present invention.

FIG. 5 is an illustration of a hierarchy within a hypotheticalorganization, arranged as a tree, that is has an alias referencing adifferent branch of the tree, according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The X.500 prior art attempts at implementation have been unable toovercome the relatively basic structural and operational differencesbetween the X.500 requirements and functionality and SQL. The X.500standard has a particular structure by nature, whereas SQL is designedto operate on relational structured tables.

For a typical relational database application, the nature of data iswell known, i.e. tables will consist of a number of columns and eachcolumn contains data relating to a particular data type (see Table B1).The different data types that can be stored is limited to the columns ofthe table. The data types are also limited to the types supported by thedatabase (e.g. string, numeric, money, date). The database may alsostore data of a form not understood by the database per se, butunderstood by the application e.g. binary data.

                  TABLE B1                                                        ______________________________________                                        Employee Table                                                                    Name     Surname     Title      Phone                                     ______________________________________                                        Chris    MASTERS     Sales Manager                                                                              03 727-9456                                   Alana MORGAN Sales Support 03 727-9455                                        . . . . . . . . . . . .                                                     ______________________________________                                    

If a new data type needs to be added (e.g. mobile) then a new columnwill have to be added to the table. This can cause problems if datatable changes are not easy to implement. Also if the new data type isnot well used (e.g. less than 1% of the organisation) then significantredundant data storage may result. See Table

                  TABLE B2                                                        ______________________________________                                        Employee Table                                                                  Name    Surname   Title     Phone   Mobile                                  ______________________________________                                        Chris MASTERS   Sales Manager                                                                             03 727-9456                                                                           018 042671                                  Alana MORGAN Sales Support 03 727-9455                                        . . . . . . . . . . . . . . .                                               ______________________________________                                    

In essence, one invention in the application of X.500 resides inovercoming the extensibility by representing the X.500 attributes of theprior art:

    ______________________________________                                        empl #    name           age   salary                                         ______________________________________                                    

as described above, as

    ______________________________________                                        type           syntax  value,                                                 ______________________________________                                    

the latter representation being an extensible representation and is thusadapted to implementation with SQL. The latter representation is knownas meta-data. The meta-data "value" may be binary.

A further development based on the above principle design is theadaption of the `principle design` to X.500. This adaption has beenrealized by the provision of a `property table`, in which object nameand parent name is added to the `principle design`.

Further benefits accrue from the implementation disclosed above;including:

a. independence of complexity of filter--the implementation disclosedmay utilise a query optimiser provided in SQL, and therefore there is noneed to replicate a query optimiser in each proprietary database towhich the present invention is applied,

b. independence of size--the implementation disclosed has the ability tobe scaled,

c. independence of depth of tree--the implementation disclosed hashierarchy comparability,

d. performance--if index is put on the type column, then each and everytype is indexed.

2. Conceptual Design

The prior art has had difficulty in implementing X.500 as it has notbeen structured for extensibility, object oriented and hierarchy whichare requirements of X.500.

This is a dressed, in one form, by functionally decomposing the`property table` and thus resulting in what is called the ConceptualDesign.

The conceptual design resides in providing at least one of:

1. Attribute table, where extensibility is addressed by allowing thedefinition of a new attribute type in this table by adding a row to thetable;

2. Object table, which defines the attributes within each object; and/or

3. Hierarchy table, which defines the relationship between the objects.

In another invention, this problem is addressed by providing tablestructures in accordance with those disclosed in FIGS. 2A and 2B.

Yet further inventions reside in addressing problems of data toleranceby providing in the present X.500 system for the replacement of the`value` column of the object table with value `norm` and value `raw`columns and/or replacing the RDN column in the hierarchy table with`name norm` and `name raw` columns.

Further, the difficulty in prior art of accommodating aliases isaddressed in the present X.500 system by providing an `alias` column inthe hierarchy table. The `alias`column is flagged to indicate that, thatentry is an alias.

Further refinement may be provided by replacing the `alias` column withalias and A-EID columns. The A-EID provides information about where thealias points.

Still further refinement may be provided by replacing the `alias` columnin the hierarchy table with `parent` and `path` columns.

The `path` addresses the problem of implementing X.500 search, withaliases and subtrees. The `path` has at least two unique properties: a)to determine the absolute position in the hierarchy; and b) it is usedto determine if an entry is in a given subtree by its prefix.

3. Conceptual Method

A number of unique method of interrogating the conceptual design aredisclosed in the detailed description following, including:

a) mapping the X.500 services into a sequence of SQL statements;

b) the search strategy is to apply the filter over the search area usingthe path or parent columns, and/or;

c) in dealing with aliases during navigation--where an alias points iscached in the A₋₋ EID column;

d) in dealing with alias during search--find the unique set of baseobjects which define areas of the tree that need to be searched, andthen apply b) above to each area of the tree.

A further invention is realized by using the attribute table forincoming data to find the AID from the X.500 object ID and outgoing dataread from the database, vice versa.

Furthermore, for any incoming distinguished name, it is navigated to itsappropriate EID, then each search is performed as required by X.500.

Still furthermore, for a search, filter and subtree searches can beprovided by a single pass resolution and using the path column. Oneinvention is to utilize a `path` field to simultaneously apply anarbitrary filter over an arbitrary subtree. The complications of aliasesis handled by applying the above method to a uniquely resolved subtree.

Yet another unique method is to store the "path" of each entry as astring. Each path will then be prefixed by the path of its parent entry.This is useful for the filter in the search service.

4. Logical Design

The logical design is based on a service decomposition of the conceptualdesign, though the realization that X.500 service components areindependent.

The advantages accruing from this include:

1. Reduces the number of indexes per table, as more tables are provided.It has been found that primary indexes are most efficient (speed, size)and secondary indexes may have large overheads (speed, size).

2. Enable data in tables to be clustered. Clustering occurs as a resultof its primary key (storage structure) and thus data may be organised ondisk around its key. E.g. for the `search` table, surnames may beclustered together.

3. Management--smaller tables are easier to manage, e.g. faster toupdate indexes, collect statistics, audit, backup, etc.

4. Reduced I/O--speed improvements due to smaller rows, means more rowper page and thus operations perform less I/O's.

5. Logical Methods

A number of unique method of interrogating the logical design tables aredisclosed in the detailed description following.

In addition, one method resides in caching the attribute table. Thus,(with the exception of initial loading) no SQL statements are issued tothe database. In the present X.500 system, conversions are performed inmemory. This provides a substantial speed advantage.

Further, validation is performed in memory which avoids databaseroll-back. Roll-backs are time and system consuming.

Still further, for the arbitrary filter, a dynamic SQL equivalent isbuilt. This enables arbitrary complexity in X.500 searches.

Also for search results, the present system utilizes set orientationqueries of SQL to avoid `row at a time` processing. Thus search resultsmay be assembled in parallel in memory.

6. Physical Design

New tables and new columns are introduced to overcome column width andkey size restrictions and to achieve space optimisations.

The following text is a disclosure of embodiments of the inventionsoutlined:

1. Principle Design

With reference to FIG. 2A, the principle design addresses the basicproblem of representing the extensible, object oriented and hierarchicalnature of X.500 in relational tables. In this section it will bedisclosed (with examples) that the principle table design can berepresented by a single table as shown in Table 1 below.

                  TABLE 1                                                         ______________________________________                                        X.500 Property Table                                                          ______________________________________                                        object name                                                                              parent name                                                                             type      syntax                                                                              value                                    ______________________________________                                    

Throughout this and the following sections all column names and theirpositions in each table are arbitrary. The intent is to define what theycontain and how they are used.

1.1 Extensibility

For a typical relational database application, the nature of data iswell known, i.e., tables will consist of a number of columns and eachcolumn contains data relating to a particular data type (see Table1.1a). The table is self descriptive, i.e. the relations between dataitems is implied by being on the same row (this is the basis ofrelational theory).

                  TABLE 1.1a                                                      ______________________________________                                        Typical relational table                                                          name     surname     title      phone                                     ______________________________________                                        Chris    MASTERS     Sales Manager                                                                              03 727-9456                                   Alana MORGAN Sales Support 03 727-9455                                        . . . . . . . . . . . .                                                     ______________________________________                                    

However, the above approach is not extensible because the number ofdifferent data types is limited to the number of columns of the table.If a new data type needs to be added (e.g. mobile phone number) then anew column will have to be added to the table (see Table 1.1b). Anyapplication accessing this table will need to be updated to explicitlyquery it.

                  TABLE 1.1b                                                      ______________________________________                                        Relational table with an extra column                                           name    surname   title     phone   mobile                                  ______________________________________                                        Chris MASTERS   Sales Manager                                                                             03 727-9456                                                                           018 042671                                  Alana MORGAN Sales Support 03 727-9455                                        . . . . . . . . . . . . . . .                                               ______________________________________                                    

Other problems also exist in practice. If the new data type is not wellused (e.g. less than 1% of the organization has a mobile phone) then thetable will be sparse (e.g. if a given person does not have a mobile thenthat row/column entry will be NULL). Also, the data types are limited tothe types supported by the database (e.g. string, numeric, money, date,etc.).

The solution is to treat the data types as generic. The presentinvention adopts the method of representing arbitrary attributes (e.g.XOM [X/OPEN Object Management] API [Application Programming Interface])as a type, syntax, value combination (see Table 1.1c)

                  TABLE 1.1c                                                      ______________________________________                                        Representing arbitrary attributes                                                   type        syntax       value                                          ______________________________________                                        Name          String       Chris                                                Surname String MASTERS                                                        Title String Sales Manager                                                    Phone Numeric 03 727-9456                                                     Mobile Numeric 018 042671                                                   ______________________________________                                    

1.2 Object Oriented

X.500 defines objects (e.g. people, organizations, etc.) which maycontain an arbitrary number of "attributes". Since many objects mustappear in the table a mechanism is required to distinguish each object.An "object name" column is added to the table for this purpose (seeTable 1.2a).

                  TABLE 1.2a                                                      ______________________________________                                        Representing objects with arbitrary values                                        object name type      syntax  value                                       ______________________________________                                        Chris Masters                                                                             Name      String    Chris                                           Chris Masters Surname String MASTERS                                          Chris Masters Title String Sales Manager                                      Chris Masters Phone Numeric 03 727-9456                                       Chris Masters Mobile Numeric 018 042671                                       Alana Morgan Name String Alana                                                Alana Morgan Surname String MORGAN                                            Alana Morgan Title String Sales Support                                       Alana Morgan Phone Numeric 03 727-9455                                      ______________________________________                                    

The above method allows any number of attributes to be assigned(related) to an entry. These attributes could be of arbitrary complexity(e.g. a multi-line postal address could be handled). As the number ofcolumns is fixed new attributes can be added to any object withouthaving to redefine the application. If a new attribute is added then anapplication that reads the entry will get back an extra row.

1.3 Hierarchical

A method of representing hierarchical systems (e.g. parts explosion) isto use a parent/child combination (see Table 1.3a)

                  TABLE 1.3a                                                      ______________________________________                                        Parts explosion hierarchy                                                              parent         child                                                 ______________________________________                                               car          engine                                                      car fuel system                                                               . . . . . .                                                                   engine carburettor                                                            engine pistons                                                                . . . . . .                                                                   carburettor fuel valve                                                        carburettor air valve                                                         . . . . . .                                                                 ______________________________________                                    

X.500 defines its objects to be hierarchical. The relationships betweenobjects follow a tree structure where each object has a parent objectand each parent can have zero or more children. This relationship can berepresented in a general PROPERTY table by the addition of a "parentname" column, which is used to store the name of the parent object (seeTable 1.3b).

                  TABLE 1.3b                                                      ______________________________________                                        X.500 Property Table                                                            object name                                                                              parent name                                                                             type    syntax value                                   ______________________________________                                        Datacraft                                                                              root      Organization                                                                            String Datacraft                                   Datacraft root Address Postal PO Box 353                                         Address Croydon VIC                                                        Chris Masters Datacraft Name String Chris                                     Chris Masters Datacraft Surname String MASTERS                                Chris Masters Datacraft Title String Sales Manager                            Chris Masters Datacraft Phone Numeric 03 727-9456                             Chris Masters Datacraft Mobile Numeric 018 042671                             Alana Morgan Datacraft Name String Alana                                      Alana Morgan Datacraft Surname String MORGAN                                  Alana Morgan Datacraft Title String Sales Support                             Alana Morgan Datacraft Phone Numeric 03 727-9455                            ______________________________________                                    

Note that the root of the tree has no parent. Thus, if both Chris andAlana work for Datacraft and Datacraft is a child of the root then wecan say that Chris and Alana are children of Datacraft and thatDatacraft is the parent of Chris and Alana.

2. Conceptual Design

In Section 1 it was shown that a single Property Table could representthe extensible, object oriented and hierarchical nature of X.500 (seeTable 2a).

                  TABLE 2a                                                        ______________________________________                                        Property Table                                                                ______________________________________                                        object name                                                                              parent name                                                                             type      syntax                                                                              value                                    ______________________________________                                    

With reference to FIG. 2A in this section it will be shown that fullX.500 functionality can be represented by using three tables as shownbelow (see Table 2b and FIG. 2A).

                  TABLE 2b                                                        ______________________________________                                        Full Conceptual Table                                                         ______________________________________                                        Hierarchy Table                                                                 EID     Parent  Path Alias A.sub.-- EID                                                                        NameNorm                                                                              NameRaw                            Object Table                                                                    EID       AID    VID    Disting                                                                             ValueNorm ValueRaw                            Attribute Table                                                                     AID    Type         Syntax                                                                              ObjectId                                      ______________________________________                                    

The conceptual design addresses major problems with implementing fullX.500 functionality in relational tables. As each major design issue ispresented, examples are provided to illustrate the solution.

2.1 Functional Decomposition

The property Table (FIG. 2A) can be decomposed into separate tables thatreflect the hierarchical, object oriented and extensible nature ofX.500, preferably as follows;

a Hierarchy Table which defines the structural relationship betweenobjects.

an Object Table which defines the attribute values within each object.

an Attribute Table which defines the different attribute types.

These tables result from a process called functional decomposition.

To address the problem of correlating the relationships between tables,arbitrary numeric identifiers are introduced. The EID or "entryidentifier" correlates each object with its hierarchy information. TheAID or "attribute identifier" correlates each value in the object tablewith its attribute information.

The design is considered very efficient because the repeating groups inthe Property table (type-syntax and object name-parent name) have beenremoved. Also, for SQL, the joining columns are simple integers.

                  TABLE 2.1                                                       ______________________________________                                        Basic Conceptual Design                                                       ______________________________________                                        Hierarchy Table                                                                      EID    Parent          Name                                            ______________________________________                                          10  0 Datacraft                                                               30 10 Chris Masters                                                           31 10 Alana Morgan                                                          ______________________________________                                        Object Table                                                                        EID    AID           Value                                              ______________________________________                                          10 10 Datacraft                                                               10 16 PO Box 123 CROYDON                                                      30  3 Chris                                                                   30  4 MASTERS                                                                 30 12 Sales Manager                                                           30 20 03 727-9456                                                             31  3 Alana                                                                   31  4 MORGAN                                                                  31 12 Sales Support                                                           31 20 03 727-9455                                                           ______________________________________                                        Attribute Table                                                                 AID           Type          Syntax                                          ______________________________________                                           3 Name string                                                                 4 Surname string                                                             10 Organization string                                                        12 Title string                                                               16 Postal Address address string                                              20 Phone telephone string                                                   ______________________________________                                    

2.2 X.500 Attributes

X.500 attributes have a protocol identifier which is transferred whenany data is communicated between end systems. These identifiers areinternationally defined and are called OBJECT IDENTIFIERS (e.g. 2.5.4.4means a surname string). Thus an "ObjectId" column can be added to theAttribute table so that conversions between X.500 object identifiers andthe internal attribute identifiers can be performed.

In addition, X.500 allows an attribute to have an arbitrary number ofvalues (e.g. the mobile phone could be treated just as a secondtelephone number). Thus a "value identifier" or VID is introduced toidentify values within an attribute in the Object Table.

                  TABLE 2.2                                                       ______________________________________                                        Conceptual Design with X.500 attributes                                       ______________________________________                                        Hierarchy Table                                                                      EID    Parent          Name                                            ______________________________________                                          10  0 Datacraft                                                               30 10 Chris Masters                                                           31 10 Alana Morgan                                                          ______________________________________                                        Object Table                                                                    EID         AID    VID      Value                                           ______________________________________                                          10 10 1 Datacraft                                                             10 16 1 PO Box 123 CROYDON                                                    30  3 1 Chris                                                                 30  4 1 MASTERS                                                               30 12 1 Sales Manager                                                         30 20 1 03 727-9456                                                           30 20 2 018 042671                                                            31  3 1 Alana                                                                 31  4 1 MORGAN                                                                31 12 1 Sales Support                                                         31 20 1 03 727-9455                                                         ______________________________________                                        Attribute Table                                                                 AID       Type         Syntax     ObjectId                                  ______________________________________                                           3 Name string 2.5.4.3                                                         4 Surname string 2.5.4.4                                                     10 Organization string 2.5.4.10                                               12 Title string 2.5.4.12                                                      16 Postal Address address string 2.5.4.16                                     20 Phone telephone string 2.5.4.20                                          ______________________________________                                    

2.3 X.500 Names

In X.500, each entry uses one or more of its attribute values(Distinguished Values) for naming the entry. A "Disting" column is addedto the Object Table to flag the distinguished values.

The Distinguished Values combine to form a Relative Distinguished Name(RDN) which names the entry. The "Name" column in the Hierarchy tablestores the RDN. This is an optimization that negates the need for theRDN to be constructed from the distinguished values in the Object table.

An entry is uniquely named by a Distinguished Name (DN) which consistsof all the RDN's of the of its ancestors down from the root and the RDNof the object itself. An innovation is to add a "path" column to theHierarchy table which defines the absolute position of the entry in thetree as a list of EID's. The path as three important properties;

1) enables fast construction of DN's, (the EID list defines all theRDN's)

2) enables fast subtree searches (see Conceptual Methods),

3) it is independent of its DN (any of the RDN's in the DN can berenamed without affecting the path).

                  TABLE 2.3                                                       ______________________________________                                        Conceptual Design with X.500 attributes and names                             ______________________________________                                        Hierarchy Table                                                                 EID         Parent     Path   Name                                          ______________________________________                                          10  0 10. Datacraft                                                           30 10 10.30. Chris, MASTERS                                                   31 10 10.31. Alana, MORGAN                                                  ______________________________________                                        Object Table                                                                      EID    AID      VID  Disting Value                                        ______________________________________                                          10 10 1 1 Datacraft                                                           10 16 1 0 PO Box 123 CROYDON                                                  30  3 1 1 Chris                                                               30  4 1 1 MASTERS                                                             30 12 1 0 Sales Manager                                                       30 20 1 0 03 727-9456                                                         30 20 2 0 018 042671                                                          31  3 1 1 Alana                                                               31  4 1 1 MORGAN                                                              31 12 1 0 Sales Support                                                       31 20 1 0 03 727-9455                                                       ______________________________________                                        Attribute Table                                                                 AID        Type         Syntax     ObjectId                                 ______________________________________                                           3 Name string 2.5.4.3                                                         4 Surname string 2.5.4.4                                                     10 Organization string 2.5.4.10                                               12 Title string 2.5.4.12                                                      16 Postal Address address string 2.5.4.16                                     20 Phone telephone string 2.5.4.20                                          ______________________________________                                    

2.4 X.500 Aliases

X.500 also has the concept of `aliases`. An alias object effectivelypoints to another entry and thus provides an alternate name for thatentry. Thus an "alias" flag is added to the Hierarchy Table. When analias is discovered during Navigation (i.e. the supplied DN contains analias), then the alias value must be read from the Object Table. Thisalias DN must be resolved to where the alias points before Navigation ofthe original entry can continue.

An innovation is to use an "aliased EID" column or A₋₋ EID to store"where" the alias "points to". This removes the need to repeatedlynavigate through an alias.

                  TABLE 2.4                                                       ______________________________________                                        Conceptual Design with X.500 attributes, names and aliases                    ______________________________________                                        Hierarchy Table                                                                 EID     Parent   Path   Alias A.sub.-- EID                                                                         Name                                   ______________________________________                                          10  0 10. 0 0 Datacraft                                                       30 10 10.30. 0 0 Chris, MASTERS                                               31 10 10.31. 0 0 Alana, MORGAN                                                35 10 10.35. 1 31  Support Engineer                                         ______________________________________                                        Object Table                                                                      EID    AID      VID  Disting Value                                        ______________________________________                                          10 10 1 1 Datacraft                                                           10 16 1 0 PO Box 123 CROYDON                                                  30  3 1 1 Chris                                                               30  4 1 1 MASTERS                                                             30 12 1 0 Sales Manager                                                       30 20 1 0 03 727-9456                                                         30 20 2 0 018 042671                                                          31  3 1 1 Alana                                                               31  4 1 1 MORGAN                                                              31 12 1 0 Sales Support                                                       31 20 1 0 03 727-9455                                                         35  4 1 1 Support Engineer                                                    35  7 1 0 Datacraft/Alana, Morgan                                           ______________________________________                                        Attribute Table                                                                 AID       Type        Syntax      ObjectId                                  ______________________________________                                           1 Alias Name Distinguished Name 2.5.4.1                                       3 Name string 2.5.4.3                                                         4 Surname string 2.5.4.4                                                     10 Organization string 2.5.4.10                                               12 Title string 2.5.4.12                                                      16 Postal Address address string 2.5.4.16                                     20 Phone telephone string 2.5.4.20                                          ______________________________________                                    

2.5 X.500 Data Tolerance

Every X.500 attribute has a (internationally defined) syntax. X.500attribute syntaxes define how each attribute should be treated. In allstring syntaxes (e.g. Printable, Numeric etc.) superfluous spaces shouldbe ignored. In some syntaxes the case is not important (e.g. Case IgnoreString and Case Ignore List) and so the names "Chris Masters", "ChrisMASTERS" and " ChRis MaSTeRS " are considered identical.

In order to do comparisons (e.g. search for a particular value), thesyntax rules can be applied to create a normalized form (e.g. "CHRISMASTERS"). If this normalized form is stored in the database, then anyvariations in input form are effectively removed, and exact matching canbe used (which is necessary when using SQL).

Both the normalized data and "raw" data are stored in the database. The"raw" data is necessary so that users can retrieve the data in exactlythe same format as it was originally input. As per the X.500 and LDAPstandard, data received from a user, raw data, accords with ASN.1.(Abstract Syntax Notation No. 1). Thus the "Name" column in theHierarchy Table becomes the "NameRaw" and a "NameNorm" column is added.Similarly, the "Value" column in the Object Table becomes the "ValueRaw"and a "ValueNorm" column is added.

                                      TABLE 2.5                                   __________________________________________________________________________    Full Conceptual Design                                                        __________________________________________________________________________    Hierarchy Table                                                               EID Parent                                                                            Path                                                                              Alias                                                                            A.sub.-- EID                                                                      NameNorm   NameRaw                                         __________________________________________________________________________      10  0 10. 0 0 DATACRAFT Datacraft                                             30 10 10.30. 0 0 CHRIS, MASTERS Chris, MASTERS                                31 10 10.31. 0 0 ALANA, MORGAN Alana, MORGAN                                  35 10 10.35. 1 31  SUPPORT ENGINEER Support Engineer                        __________________________________________________________________________    Object Table                                                                  EID AID                                                                              VID                                                                              Disting                                                                           ValueNorm   ValueRaw                                            __________________________________________________________________________      10 10 1 1 DATACRAFT Datacraft                                                 10 16 1 0 PO BOX 123 CROYDON PO BOX 123 CROYDON                               30  3 1 1 CHRIS Chris                                                         30  4 1 1 MASTERS MASTERS                                                     30 12 1 0 SALES MANAGER Sales Manager                                         30 20 1 0 037279456 03 727-9456                                               30 20 2 0 018321435 018 042671                                                31  3 1 1 ALANA Alana                                                         31  4 1 1 MORGAN MORGAN                                                       31 12 1 0 SALES SUPPORT Sales Support                                         31 20 1 0 037279455 03 727-9455                                               35  4 1 1 SUPPORT ENGINEER Support Engineer                                   35  7 1 0 DATACRAFT/ALANA Datacraft/Alana, Morgan                                 MORGAN                                                                  __________________________________________________________________________    Attribute Table                                                               AID    Type       Syntax       ObjectId                                       __________________________________________________________________________       1 Alias Name Distinguished Name 2.5.4.1                                       3 Name Case Ignore String 2.5.4.3                                             4 Surname Case Ignore String 2.5.4.4                                         10 Organization Case Ignore String 2.5.4.10                                   12 Title Case Ignore String 2.5.4.12                                          16 Postal Address Case Ignore List 2.5.4.16                                   20 Phone Telephone String 2.5.4.20                                          __________________________________________________________________________

3. Conceptual Methods

This section introduces the basic X.500 services and shows how theconceptual table design, shown in Table 3a or FIG. 2A, is sufficient toimplement X.500 services and their complexities.

                  TABLE 3a                                                        ______________________________________                                        Conceptual Table Design                                                       ______________________________________                                        Hierarchy Table                                                                 EID     Parent  Path Alias A.sub.-- EID                                                                        NameNorm                                                                              NameRaw                            Object Table                                                                    EID       AID    VID    Disting                                                                             ValueNorm ValueRaw                            Attribute Table                                                                     AID    Type         Syntax                                                                              ObjectID                                      ______________________________________                                    

The example hierarchy shown in Table 3b as seen in FIG. 4, will be usedto illustrate these services. Each name in the diagram represents anobject entry in the database. The triangle represents an alias entry,and the dotted line represents the connection between the alias entryand the object that it points to. The numbers next to each entry are theentry EID's.

In the example, entry "1" has an RDN with a value of "Datacraft", entry"11" has an RDN with a value of "Sales", entry "20" has an RDN with avalue of "Network Products" and entry "31" has an RDN with a value of"Alana Morgan". The DN of entry "31" is made up of a sequence of RDN's,namely, ""Datacraft", "Sales", "Network Products", "Alana Morgan".

The alias entry "Datacraft/Networks" points to the entry "Datacraft","Sales", "Network Products". When navigating to this entry the navigateprocess would find the alias entry, then find the DN of the objectpointed to by the alias and then navigate from the root to the objectentry returning EID of "20" and a path of "1.11.20.".

Listed below are sample tables which show how data is stored. TheHierarchy table (Table 3c) shows how the entries for the examplehierarchy are stored. The Attribute table (Table 3e) shows attributeswhich are contained in the entry "Datacraft/Sales/Network Products/ChrisMasters". The Object table (Table 3d) shows how the values of theseattributes are stored.

                                      TABLE 3c                                    __________________________________________________________________________    Sample Hierarchy Table                                                        EID                                                                              Parent                                                                            Path  Alias                                                                            A.sub.-- EID                                                                      NameNorm    NameRaw                                       __________________________________________________________________________     1  0  1.    0  0   DATACRAFT   [Datacraft]                                     10  1 1.10. 1 20  NETWORKS [Networks]                                         11  1 1.11. 0 0 SALES [Sales]                                                 12  1 1.12. 0 0 MARKETING [Marketing]                                         20 11 1.11.20. 0 0 NETWORK PRODUCTS [Network Products]                        30 20 1.11.20.30. 0 0 CHRIS MASTERS [Chris Masters]                           31 20 1.11.20.31. 0 0 ALANA MORGAN [Alana Morgan]                             32 20 1.11.20.32. 0 0 PETER EVANS [Peter Evans]                             __________________________________________________________________________

                  TABLE 3d                                                        ______________________________________                                        Sample Object Table                                                             EID     AID    VID  Disting                                                                             ValueNorm  ValueRaw                               ______________________________________                                        30     3     0      1     CHRIS      [Chris]                                    30  4 0 1 MASTERS [Masters]                                                   30 12 0 0 SALES MANAGER [Sales Manager]                                       30 20 0 0 03 727 9456 [(03) 727-9456]                                         30 20 1 0 018 042 671 [(018) - 042 671]                                     ______________________________________                                    

                  TABLE 3e                                                        ______________________________________                                        Sample Attribute Table                                                          AID       Type         Syntax     ObjectID                                  ______________________________________                                         3      commonName   caseIgnoreString                                                                           2.5.4.3                                        4 surname caseIgnoreString 2.5.4.4                                           12 title caseIgnoreString 2.5.4.12                                            20 telephoneNumber telephoneNumber 2.5.4.20                                 ______________________________________                                    

Distinguished Names

For the entry shown in the sample Object Table (Table 3d) two of theattributes, commonName and surname, are distinguished values (or namingvalues) which combine to form the RDN for the entry. This RDN is storedin the Hierarchy Table.

Multi-valued Attributes

In X.500, it is permissible for an attribute to be multi-valued. The VIDcolumn is used to distinguish between values for an attribute. In thesample Object Table, the telephoneNumber attribute is multi-valued.

3.1 Mapping Services to SQL

3.1.1 Attribute Types and Values

Any data supplied by an X.500 service is supplied as a list ofObjectId's and their associated values. These must be converted intoAID's (using the Attribute table) and normalized values (using theObject table) for use by the X.500 application. The database returnsdata s AID's and Raw Values, which must then be converted intoObjectId's and their associated values in the X.500 result.

3.1.2 Navigation

Each X.500 service supplies a Distinguished Name which is converted intoan EID for use by the X.500 application. When the application processesa service it returns one or more EID's. These EID's can then betranslated back into Distinguished Names in the X.500 result.

All X.500 services rely on navigating the directory tree. To navigate toa particular entry, the following procedure is preformed:

Given the DN for the entry, locate the entry in the hierarchy tablewhich has an RDN equal to the first RDN in the DN.

Store the EID.

Recursively, locate the entry which as an RDN equal to the next RDN inthe DN and a parent equal to the stored EID.

Example

Navigate to the entry "Datacraft/Sales/Network Products/Peter Evans".This will result in a number of select statements, with each returnedEID being used as the value of the PARENT in the next statement.

select EID from HIERARCHY

where PARENT=0 and RDN="DATACRAFT"

select EID from HIERARCHY

where PARENT=1 and RDN="SALES"

select EID from HIERARCHY

where PARENT=11 and RDN="NETWORK PRODUCTS"

select EID from HIERARCHY

where PARENT=20 and RDN="PETER EVANS"

3.1.3 Read

Selected attributes to be read can be supplied. Only the values of theseattributes (if they are present in the entry) will be returned.

`Types only` can be selected as a read option, in which case no valueswill be returned. All types present in the entry, or those selected,will be returned.

Navigate to the entry to be read. Store the EID. In the Object Table,read the values of all rows which match the stored EID.

Example

Read the entry "Datacraft/HQ/Network Products" and return all types andvalues.

Navigate to the entry (as in 3.1.2) and then;

select AID, VALUERAW from OBJECT where EID=20

3.1.4 Compare

Compare returns a `matched` or `not matched` result. A raw value isinput but the compare is performed using the normalized value.

Navigate to the required entry. Store the EID. In the Object Table, testfor a matching value in all rows which match the stored EID and thespecified AID.

Example

Compare the telephone Number "03 727 9256" with the entry"Datacraft/Sales/Network Products/Chris Masters".

Navigate to the entry and then;

select VALUERAW from OBJECT where EID=30

and AID=20

and VALUENORM="03 727 9456"

If a value is selected then return "matched" else return "not matched".

3.1.5 List

Navigate to the required entry. Store the EID. In the Hierarchy Table,return the RDN's for all rows with a parent matching the stored EID.

Example

List from the entry "Datacraft/Sales".

Navigate to the entry and then;

select NAMERAW from HIERARCHY where PARENT=11

3.1.6 Add Entry

Navigate to the required parent entry. Store the EID of the parent. Adda new EID to the Hierarchy table and add rows to the Object table foreach value in the new entry.

Example

Add a new entry under the entry "Datacraft/Sales/Network Products".

Navigate to the entry and then;

insert into OBJECT (EID, AID, VID, DISTING, VALUENORM, VALUERAW) values(33, 3, 1, 1, EDWIN MAHER, Edwin Maher)

and

insert into HIERARCHY (EID, PARENT, PATH, ALIAS, A-EID, NAMENORM,NAMERAW) values (33, 20, 1.11.20.33.,0, 0, EDWIN MAHER, Edwin Maher)

3.1.7 Remove Entry

Navigate to the required entry. Check that the entry is a leaf on thetree, (i.e. check that it has no subordinate entries on the tree). Storethe EID. Remove the entry from the Hierarchy table. In the Object Table,remove all rows which match the stored EID.

Example

Remove an entry (with EID=33) under the entry "Datacraft/Sales/NetworkProducts".

Navigate to the entry and then;

delete from OBJECT where EID=33

and

delete from HIERARCHY where EID=33

3.1.8 Modify Entry

Navigate to the required entry. Store the EID. In the Object Table, Add,Remove or Modify rows matching the stored EID.

Example

Modify the entry "Datacraft/Sales/Network Products/Alana Morgan". Addvalue--title="Branch Manager".

Navigate to the entry and then;

select EID, AID, VID, VALUENORM from OBJECT where EID=31

Test the returned rows for an attribute of title. If none exist, theattribute can be added, otherwise the attribute must be checked to seeif it can be multi-valued and whether it already exists.

Insert into OBJECT (EID, AID, VID, DISTING, VALUENORM, VALUERAW) values(31,12,1,0, BRANCH MANAGER, Branch manager).

3.1.9 Modify RDN

Navigate to the required entry. Check that the new name (RDN) does notexist in the current level of the subtree (i.e. that the new DN isdistinct). Store the EID. Modify the entry in the Hierarchy and Objecttables.

Example

Modify the RDN of the entry "Datacraft/Sales/Network Products/ChrisMasters" to "Christine Masters".

Navigate to the entry and then;

select EID from HIERARCHY where PARENT=20

and VALUENORM="CHRISTINE MASTERS"

If no entries are returned then the new RDN may be inserted. First setthe old RDN to be a non-distinguished value.

update OBJECT

set DISTING=0 where EID=30 and VALUENORM="CHRIS"

and

update HIERARCHY

set NAMENORM="CHRISTINE MASTERS" and

set NAMERAW="Christine Masters"where EID=30

and

insert into OBJECT (EID, AID, VID, DISTING, VALUENORM, VALUERAW) values(30, 3, 1, 1, "CHRISTINE", "Christine")

3.2 Search Strategy

The most powerful and useful X.500 service is the search service. Thesearch service allows an arbitrary complex filter to be applied over aportion of the Directory Information Tree (the search area).

A filter is a combination of one or more filter items connected by theoperators AND, OR and NOT. For example; surname="MASTERS" ANDtitle="SALES MANAGER"

The Search area is the part of the tree that is covered by the scope ofthe search (base-object-only, on-level or whole-subtree).

One technique for resolving searches is to apply the filter and then tosee if any matching entries are in the search area. In this case afilter is applied to the entire tree and EID's for all rows matching thefilter are returned. Then, for each EID found, step search up throughthe hierarchy to see if the entry is a subordinate of the base object(i.e. the entry has a parent/grandparent/ . . . that is the baseobject). If the number of matches is large and the subtree small this isvery inefficient. This technique doesn't cope with aliases as an aliasis not a parent of the object that it points to and many aliases maypoint to a single object.

A second strategy is to obtain a list of all EID's in the search areaand then apply the filter to these EID's. If an alias is resolved thatpoints outside of the original search area then the subtree pointed toby the alias is expanded and the EID's in that subtree are added to thelist. The filter is then applied to the set of expanded EID's. This isvery poor if the search area is large.

An innovation is to simultaneously apply the filter over the search area(instead of sequentially as in the two methods described above). This iscalled single pass resolution. This method is considered to provideconsiderable performance improvement over the above methods because therows that are retrieved are those that satisfy both the filter and scoperequirements of the search.

When performing a one level search the filter is applied to all entriesthat have a parent equal to the EID of the base object (for example;search where parent=20 will apply the filter to entries 30, 31 and 32).

When performing a subtree search the path is used to expand the searcharea. The "path" of each entry is a string of numbers (e.g."1.10.50.222." which indicates that entry 222 has a parent of 50, agrandparent of 10 and a great grandparent of 1). The path has the uniqueproperty that the path of an entry is a prefix of the path of allentries that are subordinate to the entry. That is the path of an entryforms the prefix of the paths of all entries in the subtree below theentry. Therefore when performing a subtree search we obtain the baseobject of the subtree and then apply the filter to all entries that havea path which is prefixed by the path of the base object (for example; tosearch for all entries under "Sales" we perform a search where PATH LIKE1.11.%).

Base Object Search

Navigate to the base object. Store the EID. In the Object Table, readnominated values from rows which match the stored EID where a filtercriteria is satisfied, e.g., telephone prefix="727".

Example

Search from the base object "Datacraft/Sales/Network Products" for anentry with surname="MORGAN", using a "base-object-only" search.

Navigate to the base object and then;

select AID, VALUERAW from OBJECT where EID=20 and AID=4 and NAMENORM"MORGAN"

One Level Search

Navigate to the base object. Store the EID. Return the list of EID'swhich have a parent EID matching the stored EID (in Hierarchy table) andhave values which satisfy the filter criteria (OBJECT table). In theObject Table, read nominated values for the returned EID's.

Example

Search from the base object "Datacraft/Sales/Network Products" for anentry with surname="MORGAN", using a "base-object-only" search.

Navigate to the base object and then;

select H.EID from HIERARCHY H, OBJECT O where PARENT=20 and AID=4 andNAMENORM="MORGAN"

and H.EID=O.EID

then place the EID's returned into an EIDLIST and

select AID, VALUERAW from OBJECT where EID in [EIDLIST]

Subtree Search

Navigate to the base object. Store the EID. Return the list of all EID'swith a path like that of the base object (Hierarchy table) and havevalues which satisfy the filter criteria (OBJECT table). In the ObjectTable, read nominated values for the returned EID's.

Example

Search from the base object "Datacraft/Sales/Network Products" for anentry with surname="MORGAN", using a "base-object-only" search.

Navigate to the base object and then;

select H.EID from HIERARCHY H, OBJECT O where PATH like "1.11.20.%" andAID=4

and NAMENORM="MORGAN"

and H.EID=O.EID

then place the EID's returned into an EIDLIST and

select AID, VALUERAW from OBJECT where EID in [EIDLIST]

3.3 Aliases and Navigate

Aliases are resolved during navigation if the "don't-dereference-alias"flag is not set and the service is not an update service (add, delete,modify, modifyRDN).

When an alias is discovered during navigation the alias must beresolved. That is, the object that the alias points to must be obtained.First we check the A₋₋ EID column of the Hierarchy table. If the A₋₋ EIDis 0 then the object that the alias points to must be obtained from theObject table and this object must then be navigated to and the resultantEID stored in the A₋₋ EID column. If this is done successfully then theremainder of the path can be navigated. By storing the EID of thealiased object in the A₋₋ EID column of the Hierarchy table it ispossible to avoid navigating to aliased objects. This can save time,especially if the aliased object is at a low level of the hierarchy.

3.4 Aliases and Search

Aliases are dereferenced during a search if the "search-aliases" flag inthe search argument is set. The performance of the search service whiledereferencing aliases becomes a two step process. Firstly, define thesearch area and then apply the filter to the entries within the searcharea. Aliases dereferenced as part of the search service can expand thesearch area to which the filter is applied. They also restrict thesearch area in that any dereferenced aliases are excluded from thesearch area.

Aliases and One Level Search

If aliases are being dereferenced as part of a one level search and analias entry is found then the alias must be resolved (using the Objecttable or the A₋₋ EID). The aliased object is then added to the searcharea to which the filter is applied. In a oneLevel search where aliasesare found the search area will consist of non-alias entries directlysubordinate to the base object and all dereferenced aliases.

Aliases and Subtree Search

If aliases are being dereferenced as part of a whole subtree search andan alias entry is found then the alias must be resolved (using theObject table or the A₋₋ EID) and this EID must then be treated asanother base object, unless it is part of an already processed sub tree.

When dereferencing aliases during a search the "Path" column can be usedto find alias entries within a subtree join. If an alias entry is foundthat points outside of the current subtree then the subtree pointed toby the alias can also be searched for aliases. One property of thehierarchical tree structure is that each subtree is uniquely representedby a unique base object (i.e. subtrees do not overlap). When performinga subtree search we build up a list of base objects which define uniquesubtrees. If no aliases are found then the list will contain only onebase object. If an alias is found that points outside of the subtreebeing processed then we add the aliased object to the list of baseobjects (unless one or more of the base objects are subordinate to thealiased object in which case the subordinate base object(s) are replacedby the aliased object). The search area will therefore consist ofnon-alias entries that have a path prefixed by the path of one of thebase objects.

4. Logical Design

Whilst the Conceptual Design (see Table 4a) is sufficient to implementthe X.500 functionality, further performance improvements can be made.

                  TABLE 4a                                                        ______________________________________                                        Conceptual Design                                                             ______________________________________                                        Hierarchy Table                                                                 EID     Parent  Path Alias A.sub.-- EID                                                                        NameNorm                                                                              NameRaw                            Object Table                                                                    EID       AID    VID    Disting                                                                             ValueNorm ValueRaw                            Attribute Table                                                                     AID    Type         Syntax                                                                              ObjectId                                      ______________________________________                                    

Performance improvements in conventional relational design can beachieved because assumptions can be made about the data--the data isessentially fixed at the time an application is designed. In X.500, noneof the data types are known. However performance improvements can stillbe made because assumptions can be made about the services--these areknown at the time the X.500 application is designed.

With reference to FIG. 2B, one innovative approach is to recognise thateach table can be organised around the major service relationships(instead of around the major data relationships in conventionalrelational design). It shall be shown that the above tables can bedecomposed into a number of smaller and more efficient tables as shownbelow.

                  TABLE 4b                                                        ______________________________________                                        Logical Design                                                                ______________________________________                                        DIT                                                                                 EID    PARENT         ALIAS RDN                                         NAME                                                                                    EID    RAW                                                          TREE                                                                                    EID    PATH                                                         ALIAS                                                                                   EID    A.sub.-- EID                                                 SEARCH                                                                          EID         AID    VID      DISTING                                                                              NORM                                     ENTRY                                                                               EID    AID            VID  RAW                                          ATTR                                                                               AID    SYNTAX        DESC  OBJECTID                                      ______________________________________                                    

4.1 Service Decomposition

The practical reality for most RDBMS's is that big tables with manycolumns do not perform as well as smaller tables with fewer columns. Themajor reasons are to do with indexing options, I/O performance and tablemanagement (see Sections 4.5 and 4.6). This is why prior art relationaldesign techniques aim to focus primary information into separate tablesand derive secondary information via table joins (i.e. normalization andfragmentation techniques).

One innovation in achieving X.500 performance is to decompose the tablesaround primary service relationships and derive secondary services viajoins. This process is called service decomposition. The followingconsiderations are made:

(1) Columns that have strong relationships are preferred to be kepttogether (to avoid unnecessary joins);

(2) If the number of significant rows in a given column is independentof the other related columns, then that given column is a candidate fora separate table.

(3) If a column is only used for locating information (input) or onlyused for returning results (output) then it is a candidate for its owntable.

(4) If a column is used as a key for more than one service then it ispreferred to be a primary key and therefore in its own table (each tablecan have only one primary key).

(5) Keys are preferred to be unique or at least strong(non-repetitious).

A first level analysis of column usage is shown in Table

                                      TABLE 4.1                                   __________________________________________________________________________    Basic column usage                                                            X.500             Value                                                                            Value                                                                            Par-   Name                                                                             Name                                          Service Table EID AID VID Norm Raw ent Alias Norm Raw Path                  __________________________________________________________________________    Navigate                                                                            H  R              S   R  S     R                                          Read O S (S)/R R  R    R R                                                    Compare O S S  S                                                              List H      S R  R                                                            Search- O S/R S  (S)  (S)    (S)                                              filter                                                                        Search-  S/R (S)/R R  R    R R                                                result                                                                        Add H/O S                                                                     Remove H/O S                                                                  Modify O S S S S                                                              Modify RDN H/O S S S     S                                                  __________________________________________________________________________

Keys to symbols in the above table:

H--Hierarchy table

O--Object table

S--Supplied value (used in the SQL for Searching the table)

R--Returned value (value retrieved from the tables)

()--item may or may not be present depending on the options of theservice.

From the above information and further analysis, the Conceptual Designtables can be decomposed into a number of smaller tables as described inthe following sections.

4.2 Hierarchy Table Decomposition

The Hierarchy table contains the following columns:

                  TABLE 4.2a                                                      ______________________________________                                        Hierarchy Table                                                               ______________________________________                                        EID   Parent  Path   Alias A.sub.-- EID                                                                        NameNorm                                                                              NameRaw                              ______________________________________                                    

The Hierarchy Table contains information about objects and theirparents, their names, their absolute positions in the hierarchy and ifthey are aliases. This table can therefore be split into four tables:DIT, NAME, TREE and ALIAS.

The parent information is used for finding a given child or acting onentries that have a given parent. Finding a given child (e.g. Parent=0,NameNorm="DATACRAFT") is the basis for Navigation and update checking(checking for the existence of an object before an Add or ModifyRdn).Acting on entries that have a given parent is used during List orOneLevel Search. Thus the DIT (Directory Information Tree) table hasinformation required for Navigation, but allows its PARENT column to beused by other services.

                  TABLE 4.2b                                                      ______________________________________                                        DIT Table                                                                     ______________________________________                                        EID      PARENT         ALIAS   RDN                                           ______________________________________                                    

An object is differentiated from its siblings via its RelativeDistinguished Name (RDN). RDN's are returned for a List (in conjunctionwith a given Parent) or as part of a full Distinguished Name (Read,Search). Thus the NAME table has information required for returningnames (the raw RDN).

                  TABLE 4.2c                                                      ______________________________________                                        NAME Table                                                                    ______________________________________                                                EID  RAW                                                              ______________________________________                                    

An object's absolute position in the hierarchy is necessary for buildingDN's (from which the raw DN's are retrieved) and for expanding subtreesduring Search. Thus the TREE table has information about an entry's Path(the sequence of EID's down from the root).

                  TABLE 4.2d                                                      ______________________________________                                        TREE Table                                                                    ______________________________________                                                EID  PATH                                                             ______________________________________                                    

Alias information is cached so that every time an alias is encounteredduring Navigate it does not have to be repeatedly resolved. Thus theALIAS table only contains entries that are aliases. It is also usedduring OneLevel Search (in conjunction with the DIT Parent column) andSubtree Search (in conjunction with the Path column) to determine ifthere are any aliases in the search area.

                  TABLE 4.2e                                                      ______________________________________                                        ALIAS Table                                                                   ______________________________________                                                EID  A.sub.-- EID                                                     ______________________________________                                    

4.3 Object Table Decomposition

The Object table contains the following columns:

                  TABLE 4.3a                                                      ______________________________________                                        Object Table                                                                  ______________________________________                                        EID     AID    VID      Disting                                                                             ValueNorm ValueRaw                              ______________________________________                                    

The Object Table essentially contains information for finding aparticular value (e.g. AID=surname, ValueNorm="HARVEY") and forretrieving values (e.g. AID=surname, ValueRaw="Harvey"). This table cantherefore be split into two tables: SEARCH and ENTRY.

The Search Table is used to resolve filters in the Search service. It isalso used to find values during Compare, Modify and ModifyRDN. TheSearch table contains one row for each attribute value of each entry.Only the normalised values are stored in this table.

                  TABLE 4.3b                                                      ______________________________________                                        SEARCH Table                                                                  ______________________________________                                        EID       AID    VID        DISTING                                                                              NORM                                       ______________________________________                                    

The Entry table is used to return values in Reads and Searches. TheEntry table contains one row for each attribute value for each entry.The RAW value is the value exactly as initially supplied when the entrywas added or modified.

                  TABLE 4.3c                                                      ______________________________________                                        ENTRY Table                                                                   ______________________________________                                        EID      AID            VID    RAW                                            ______________________________________                                    

4.4 Attribute Table

The Attribute table is essentially the same as the Conceptual Design. Inpractice the "type" field is only descriptive, since anyincoming/outgoing X.500 Object Identifier gets converted to/from theinternal attribute identifier, AID. Thus this column has been renamedDESC to signify that it is a description field.

                  TABLE 4.4                                                       ______________________________________                                        ATTR Table                                                                    ______________________________________                                        AID     SYX            DESC    ObjectId                                       ______________________________________                                    

4.5 Index Selection

Performance when using SQL is achieved because the RDBMS is able tosatisfy the query using a relevant index. This means that every querythat has a condition (the "where" clause in SQL) is preferred to have anassociated index (otherwise the RDBMS has to resort to a table levelscan). However in practical RDMS's:

The number of indexes is restricted;

There may be a high overhead to maintain secondary indexes;

Composite indexes may be required to satisfy any one query. Thus, ifperforming a query across columns (e.g., type=surname and value="SMITH")then separate indexes on type and value may not result in a fullyindexed access. A composite index on both type and value may berequired.

One innovation of the table decomposition in the previous sections is tomaximise the use of primary indexes across tables. This reduces thenumber of secondary indexes (i.e. they become primary indexes on theirown table). Following is a list of the indexes for each of the sixtables used in the logical design.

                  TABLE 4.5                                                       ______________________________________                                        Table Indexes for the Logical Design                                               Table      Primary Key    Secondary Index                                ______________________________________                                        DIT         PARENT, RDN    EID                                                  NAME EID                                                                      TREE PATH EID                                                                 SEARCH AID, NORM EID, AID, VID                                                ENTRY EID, AID, VID                                                           ATTR (cached)                                                               ______________________________________                                    

The table design means that many queries can be handled without joins,giving substantial performance improvement.

The joins that are considered necessary are listed below:

List--for returning the RAW-RDNs under a given object (DIT joined withNAME).

Search/Subtree--for finding EIDs that match a filter over a wholesubtree (where the base object is not the root) (TREE joined withSEARCH).

Search/OneLevel--for finding EIDs that match a filter one-level underthe base object (DIT joined with SEARCH).

Search/Aliases/Subtree--for finding all the aliases in a subtree (TREEjoined with ALIAS).

Search/Aliases/OneLevel--for finding all the aliases under a givenobject (DIT joined with ALIAS).

Note that the above joins are first level joins (i.e. between only twotables). It is preferable not to use higher order joins.

4.6 Input/Output Performance

An innovation of decomposing tables around services, which increases thenumber of tables, is that the new tables are much smaller than theunfragmented tables. This can significantly reduce the amount of I/O forthe following reasons:

Row Size

By reducing the number of columns in any row, the row width will beshortened. This means that more rows will fit onto a page (where it isassumed that one disk I/O returns one "page" of information). Incombination with clustering below, whenever a set of rows need to beretrieved, only one (or a few) page(s) may actually have to be read offthe disk (e.g. when reading the attributes of an object, if the ENTRYtable is keyed on EID, AID, VID then all the rows relating to thatobject will be together and will probably be on the same page).

Clustering

Each of the fragmented tables is preferred to have their own(independent) primary key which enables them to cluster data accordingto how it is used. The primary key may dictate the "storage structure".Thus in the SEARCH table, if the primary key is on AID, NORM (i.e. type,value) then all the data of the same type (e.g. surname) and similarvalues (e.g. Harvey, Harrison) will be clustered in the same area of thedisk. This means that during a Search (e.g. surnames beginning with"HAR") similar data will collected together on the one (or just a few)disk page(s). If the rows are small then the number of disk pages thathave to be accessed is significantly reduced.

Caching

Most commercial RDBMS's have the ability to cache pages frequentlyaccessed. Since tables are effectively input (e.g. Navigating using theDIT table), or output (e.g. retrieving information from the ENTRY table)then similar requests (e.g. Searches over the same portion of the Tree)will tend to result in frequently used pages being cached, meaningfrequently invoked queries will gain significant benefits. Also thecaching is more efficient since pages are "information intensive" as aresult of small row size and clustering.

Management

Smaller tables are generally easier to manage: e.g. viewing, creatingindexes, collecting statistics, auditing, backups, etc.

5. Logical Methods

This section describes methods of interrogating the Logical Designtables, with reference to FIG. 2B.

Throughout this section, each X.500 method is defined and illustratedwith an example. Referring again to FIG. 4, which will be referred to inthe following discussion as Table 5a, it can be seen that Table 5adisplays a small hierarchy tree which includes an alias reference. Thecorresponding Table contents are shown in Table 5b.

                  TABLE 5.b                                                       ______________________________________                                        Example Tables                                                                ______________________________________                                        DIT                                                                             EID       PARENT   ALIAS   RDN                                              ______________________________________                                           1  0 0 DATACRAFT                                                             10  1 1 NETWORKS                                                              11  1 0 SALES                                                                 12  1 0 MARKETING                                                             20 11 0 NETWORK PRODUCTS                                                      30 20 0 CHRIS MASTERS                                                         31 20 0 ALANA MORGAN                                                          32 20 0 PETER EVANS                                                         ______________________________________                                        NAME                                                                            EID                 RAW                                                     ______________________________________                                           1 [Datacraft]                                                                10 [Networks]                                                                 11 [Sales]                                                                    12 [Marketing]                                                                20 [Network Products]                                                         30 [Chris Masters]                                                            31 [Alana Morgan]                                                             32 [Peter Evans]                                                            ______________________________________                                         NOTE: [. . . ] indicates a binary encoding of the exact data entry value.

    TREE                                                                            EID                   PATH                                                  ______________________________________                                           1 1.                                                                         10 1.10.                                                                      11 1.11.                                                                      12 1.12.                                                                      20 1.11.20.                                                                   30 1.11.20.30.                                                                31 1.11.20.31.                                                                32 1.11.20.32.                                                              ______________________________________                                        ALIAS                                                                           EID                    A-EID                                                ______________________________________                                          10 20                                                                       ______________________________________                                        ATTRIBUTE                                                                       AID    SYX             DESC        OBJECTID                                 ______________________________________                                           0 objectIdentifierSyntax objectClass 2.5.4.0                                  1 distinguishedNameSyntax aliasedObjectName 2.5.4.1                           3 caseIgnoreStringSyntax commonName 2.5.4.3                                   4 caseIgnoreStringSyntax surname 2.5.4.4                                      7 caseIgnoreStringSyntax localityName 2.5.4.7                                 8 caseIgnoreStringSyntax stateOrProvinceName 2.5.4.8                          9 caseIgnoreStringSyntax streetAddress 2.5.4.9                               10 caseIgnoreStringSyntax organzationName 2.5.4.10                            11 caseIgnoreStringSyntax organizationalUnit- 2.5.4.11                          Name                                                                        12 caseIgnoreStringSyntax title 2.5.4.12                                      13 caseIgnoreStringSyntax description 2.5.4.13                                16 PostalAddress postalAddress 2.5.4.16                                       17 caseIgnoreStringSyntax postalCode 2.5.4.17                                 18 caseIgnoreStringSyntax postOfficeBox 2.5.4.18                              20 telephoneNumberSyntax telephoneNumber 2.5.4.20                           ______________________________________                                        SEARCH                                                                          EID     AID    VID  DISTING                                                                              NORM                                             ______________________________________                                           1  0 0 0 2.5.6.4                                                              1 10 0 1 DATACRAFT                                                            1 16 0 0 266-268 MAROONDAH HIGHWAY                                            1 17 0 0 3138                                                                10  0 0 0 2.5.6.1                                                             10  1 0 1 DATACRAFT/SALES/NETWORK                                                 PRODUCTS                                                                  11  0 0 0 2.5.6.5                                                             11 11 0 1 SALES                                                               11 13 0 0 SALES DEPARTMENT                                                    12  0 0 0 2.5.6.5                                                             12 11 0 1 MARKETING                                                           12 13 0 0 MARKETING DEPARTMENT                                                20  0 0 0 2.5.6.5                                                             20 11 0 1 NETWORK PRODUCTS                                                    20 13 0 0 NETWORK PRODUCTS SECTION                                            30  0 0 0 2.5.6.7                                                             30  3 0 1 CHRIS                                                               30  4 0 1 MASTERS                                                             30 12 0 0 SALES MANAGER                                                       30 20 0 0 03 727 9456                                                         30 20 1 0 018 042 671                                                         31  0 0 0 2.5.6.7                                                             31  3 0 1 ALANA                                                               31  4 0 1 MORGAN                                                              31 12 0 0 SALES SUPPORT                                                       31 20 0 0 03 727 9455                                                         32  0 0 0 2.5.6.7                                                             32  3 0 1 PETER                                                               32  4 0 1 EVANS                                                               32 12 0 0 SALES PERSON                                                        32 20 0 0 03 727 9454                                                       ______________________________________                                        ENTRY                                                                           EID       AID    VID    RAW                                                 ______________________________________                                           1  0 0 [2.5.6.4]                                                              1 10 0 [Datacraft]                                                            1 16 0 [266-268 Maroondah Highway]                                            1 17 0 [3138]                                                                10  0 0 [2.5.6.1]                                                             10  1 0 [Datacraft/Sales/Network Products]                                    11  0 0 [2.5.6.5]                                                             11 11 0 [Sales]                                                               11 13 0 [Sales Department]                                                    12  0 0 [2.5.6.5]                                                             12 11 0 [Marketing]                                                           12 13 0 [Marketing Department]                                                20  0 0 [2.5.6.5]                                                             20 11 0 [Network Products]                                                    20 13 0 [Network Products Section]                                            30  0 0 [2.5.6.7]                                                             30  3 0 [Chris]                                                               30  4 0 [Masters]                                                             30 12 0 [Sales Manager]                                                       30 20 0 [(03) 727-9456]                                                       30 20 1 [(018) - 042 671]                                                     31  0 0 [2.5.6.7]                                                             31  3 0 [Alana]                                                               31  4 0 [Morgan]                                                              31 12 0 [Sales Support]                                                       31 20 0 [(03) 727-9455]                                                       32  0 0 [2.5.6.7]                                                             32  3 0 [Peter]                                                               32  4 0 [Evans]                                                               32 12 0 [Salesperson]                                                         32 20 0 [(03) 727-9454]                                                     ______________________________________                                         NOTE: [. . .] indicates a binary encoding of the exact data entry value. 

5.1 Common Services

Tree Navigation

All X.500 services rely on navigating the directory tree illustrated inFIG. 3. The purpose of tree navigation is to retrieve the EID of theentry corresponding to the supplied Distinguished Name. Navigationbegins from the root of the tree and continue down the tree until allthe RDN's in a DN have been resolved (verified). This process is knownas a "Tree Walk".

The DIT Table is the primary table used for tree navigation. Referringto the example hierarchy tree illustrated as Table 5A in FIG. 3,resolution of the DN "Datacraft/Sales/Network Products/Peter Evans"involves the following processes:

Scan the DIT table for a row containing PARENT=0 and RDN="DATACRAFT".The EID for this row is 1.

Scan the DIT table for a row containing PARENT=1 and RDN="SALES". TheEID for this row is 11.

Scan the DIT table for a row containing PARENT=11 and RDN="NETWORKPRODUCTS". The EID for this row is 20.

Scan the DIT table for a row containing PARENT=20 and RDN="PETER EVANS".The EID for this row is 32.

The DN has now been resolved and any values relating to the object canbe obtained from the Entry Table using the key EID=32.

Aliases

Sometimes a DN can contain an alias, which is effectively another DN.Aliases complicate the tree walk process because the tree walk cannotcontinue until the alias is resolved. This requires a separate tree walkfor the alias.

As an example, consider the DN "Datacraft/Networks/Peter Evans". Thefirst two steps in resolving this DN would be:

Scan the DIT table for a row containing PARENT=0 and RDN="DATACRAFT".The EID for this row is 1.

Scan the DIT table for a row containing PARENT=1 and RDN="Networks"TheEID for this row is 10.

At this stage we discover that this entry is an alias. The Alias Tableis checked to see if the EID of the alias has been cached. If this isthe first time an attempt has been made to resolve this alias then theA₋₋ EID column in the Alias Table will be zero. For the purpose ofdiscussion it will be assumed that this is the first time.

To resolve the alias, the DN of the aliased object must be determined.This is stored in the "aliasedObjectName" attribute of the alias entry.The aliasedObjectName has an AID=1 (from the ATTR table) and so the DNis obtained from the Entry Table (RAW value) where EID=10 and AID=1.

In this example, the DN of the alias is "Datacraft/Sales/NetworkProducts". This DN is resolved completely using the normal tree walkingtechnique. The value of EID is 20.

At this stage, navigation continues for the unresolved RDN's in theoriginal DN, namely "PETER EVANS". The last step required is then:

Scan the DIT table for a row containing PARENT=20 and RDN="PETER EVANS".

Once an alias has been resolved it can be added (cached) in the AliasTable. This table contains a reference, A₋₋ EID, to the aliased object.In the above example, an entry in the Alias Table with an EID of 10would have an A₋₋ EID of 20. Once an alias has been cached a tree walkis no longer necessary to resolve the alias.

Directory Paths

When objects are added to the DIT table, a corresponding row is added toanother table called the Tree Table. This table stores the list of theEID's which identify a "Path" to the object.

Distinguished Names

Most services require the distinguished name to be returned in theService Result. Using the directory path from the Tree Table, a DN canbe constructed from the RAW RDN values stored in the Name Table.

Entry Information Selection

Many of the X.500 Services are requested with an argument called"EntryInformationSelection" or EIS. The EIS argument is used to indicatewhat information in the Entry should be returned. Basically, EIS can beoptionally;

no information

attributes and values for selected or all attributes

values only for selected or all attributes

Entry Information

Entry Information is a return parameter for Read and Search. It alwayscontains the Distinguished Names of selected entries and, optionally,attributes and/or values as specified in the EIS argument of therequest.

Common Arguments

All of the X.500 Services pass a set of common arguments in the ServiceRequest. Common Arguments contain information such as service controls(time limit and size limit), the DN of the requestor of the service andsecurity information.

Common Results

Some X.500 Services pass a set of common results in the ServiceResponse. Common Results contain information such as securityparameters, the DN of the performer of the service and an aliasdereferenced flag.

5.2 Read Service

A Read operation is used to extract information from an explicitlyidentified entry.

    ______________________________________                                        X.500 definition                                                              ______________________________________                                        Argument       Description                                                    ______________________________________                                          Name A Distinguished Name                                                     EntryInformationSelection The attributes and values to be returned (ie                       EIS)                                                           Common Arguments                                                            ______________________________________                                          Result Description                                                          ______________________________________                                          Entry Information The DN plus any attributes and values                        returned                                                                     Common Results                                                              ______________________________________                                    

Method

Perform a tree walk using the DIT table, resolving aliases if necessary.Obtain the base EID.

Using PATH from the Tree Table and the RAW RDN's from the Name Table,build a DN.

If EIS specifies no attributes or values, just return the DN.

If EIS specifies ALL types and values, return the RAW values from theEntry Table for the matching EID.

If EIS specifies selected types and values, obtain the AID's from theAttribute Table and then return selected types and/or values for thematching EID.

Example

Read the entry "Datacraft/Sales/Network Products/Peter Evans". EIS isset to: attribute Types=allAttributes,InfoTypes=attributeTypesAndValues.

Using the DIT table perform a Tree Walk traversing EID's 1, 11, 20 and32 for the normalised RDN's DATACRAFT, SALES, NETWORK PRODUCTS, PETEREVANS. The EID of the selected object is 32.

Extract the PATH from the Tree Table for EID=32. The PATH is 1.11.20.32.

Build aDN from the RAW values in the Name Table for EID's 1, 11, 20, 32.

Using the Entry Table and the Attribute Table, for each matching EID;

return the OBJECTID's from the Attribute Table and the ASN.1 encoded RAWvalues from the Entry Table

    ______________________________________                                        2.5.4.0           [2.5.6.7]                                                     2.5.4.3 [PETER]                                                               2.5.4.4 [EVANS]                                                               2.5.4.9 [SALESPERSON]                                                         2.5.4.20 [(03) 727-9454]                                                    ______________________________________                                    

return the DN

5.3 Compare Service

A Compare operation is used to compare a value (which is supplied as anargument of the request) with the value(s) of a particular attributetype in a particular object entry.

    ______________________________________                                        X.500 definition                                                              ______________________________________                                        Argument      Description                                                     ______________________________________                                          Name A Distinguished Name                                                     AttributeValueAssertion The attribute type and value to be compared                        Common Arguments                                               ______________________________________                                          Result Description                                                          ______________________________________                                          DistinguishedName The DN of the selected object (returned if an                             alias is dereferenced)                                          matched TRUE/FALSE result of compare                                          fromEntry N/A                                                                 Common Results                                                              ______________________________________                                    

Method

Perform a tree walk using the DIT table, resolving aliases if necessary.Obtain the EID of the base object.

From the Attribute Table, contain the AID of the attribute to becompared.

From the Entry Table, select the row(s) matching the EID and AID.

Compare the value.

Return TRUE or FALSE as the Compare result.

If an alias is dereferenced, return the DN of the selected object, usingthe path from the Tree Table and the RAW RDN's from the Name Table.

Example

Compare the DN "Datacraft/Sales/Network Products/Peter Evans" with apurported AttributeValueAssertion of "title=[Salesperson]".

Obtain the EID for the given DN using a TreeWalk. The EID of theselected object is 32.

Using the Attribute table, obtain the AID for "title", ie AID=12.

Using the Search Table locate rows with EID=32 and AID=12 and test for"NORM=SALESPERSON".

Return TRUE or FALSE depending on the outcome of this test. In thisinstance the result would be TRUE.

Since no aliases were dereferenced, the DN of the entry is not returned.

5.4 List Service

A list operation is used to obtain a list of immediate subordinates ofan explicitly identified entry.

    ______________________________________                                        X.500 definition                                                              ______________________________________                                        Argument      Description                                                     ______________________________________                                          Name A Distinguished Name                                                     Common Arguments                                                            ______________________________________                                          Result Description                                                          ______________________________________                                          DistinguishedName The DN of the selected object (returned if an                             alias is dereferenced)                                          subordinates A list of RDN's for the subordinate entries                       (aliases, indicated by an alias flag, are not                                 dereferenced)                                                                partialOutcomeQualifier An indication that an incomplete result was                         returned, eg, a time limit or size limit                         restriction.                                                                 Common Results                                                              ______________________________________                                    

Method

Perform a tree walk using the DIT table, resolving aliases if necessary.Obtain the EID of the base object.

Using the DIT and Name Tables return the ALIAS flag and the RAW RDNPARENT is equal to the EID of the base object.

Example

Perform a list for the DN "Datacraft".

Obtain the EID for the DN using a TreeWalk. The EID of the selectedobject is "1".

For each EID with a PARENT=1

return the RAW RDN from the Name Table, ie, [Network], [Sales],[Marketing]

return the alias flags, ie, TRUE, FALSE, FALSE.

As no alias were dereferenced in the tree walk, the DN of the selectedobject is not returned. Note also that the alias entry [Networks] is notdereferenced.

5.5 Search Service

The Search Service is the most complex of all X.500 services. Searcharguments indicate where to start the search (baseObject), the scope ofthe search (subset), the conditions to apply (filter) and whatinformation should be returned (selection). In addition, a flag ispassed to indicate whether aliases should be dereferenced(searchAliases).

The possible values for subset are baseObject, oneLevel andwholeSubtree. Base object indicates that the search filter will only beapplied to attributes and values within the base object. OneLevelindicates the Search filter will be applied to the immediatesubordinates of the base object. Whole subtree indicates the Searchfilter will be applied to the base object and all of its subordinates.

A simple example of a filter condition would be: surname="EVANS" ortelephoneNumber PRESENT.

    ______________________________________                                        X.500 definition                                                              ______________________________________                                        Argument     Description                                                      ______________________________________                                          baseObject The Distinguished Name of the baseObject                           subset baseObject, oneLevel or wholeSubtree                                   filter search conditions                                                      searchAliases a flag to indicate whether aliases among                         subordinates of the base object should be                                     dereferenced during the search.                                              selection EIS as for READ. The attributes and values to                        be returned.                                                                 Common Arguments                                                            ______________________________________                                          Result Description                                                          ______________________________________                                          DistinguishedName The DN of the selected object (returned if an                            alias is dereferenced)                                           entries Attributes & values (as defined in selection) for                      the entries which satisfy the filter.                                        partialOutcomeQualifier An indication that an incomplete result was                        returned, eg, a time limit or size limit                          restriction.                                                                 Common Results                                                              ______________________________________                                    

The search procedures for each search scope are outlined as follows:

Base Object

Perform a tree walk using the DIT table, resolving aliases if necessary.Obtain the EID of the base object.

Apply the filter to attributes and values in the Search Table with theEID of the selected object.

If the filter condition is matched, return the Entry Information fromthe Entry Table.

If an alias is dereferenced, return the DN using the Tree Table toextract the PATH and the Name Table to build the DN.

One Level

Perform a tree walk using the DIT table, resolving aliases if necessary.Obtain the EID of the base object.

Check to see if any aliases exist with PARENT=EID and if so resolve themto obtain an aliases dereferenced list.

Using the Search and DIT Tables, apply the filter (attribute/valueconditions) and the scope (PARENT=EID of selected object and any aliasesdereferenced). A list of matching EID's will be returned.

If an alias is dereferenced, return the DN using the Tree Table toextract the PATH and the Name Table to build the DN.

For each matching EID:

Return the Entry Information obtained from the Search Table using theEntry Table (as per Read Service).

Whole Subtree

Perform a tree walk using the DIT table, resolving aliases if necessary.Obtain the EID of the base object.

Check to see if any aliases exist with PATH prefix matching the PATH ofthe selected object.

For each alias discovered, check to see if the alias points outside thecurrent subtree and if it does repeat the previous step. Once allaliases have been resolved, a set of unique base objects will have beenfound (with no overlapping areas).

Using the Search and Tree Tables, apply the filter (attribute/valueconditions) and the scope (PATH LIKE PATH prefix of the selected object)to each unique base object. A list of matching EID's will be returned.

If an alias is dereferenced during Navigation (not during searching),return the DN using the Tree Table to extract the PATH and the NameTable to build the DN.

For each matching EID:

Return the Entry Information obtained from the Search Table using theEntry Table (as per Read Service).

Example

Perform a search on the baseObject "Datacraft/Sales" with:

Scope set to WholeSubtree

a Filter of "surname, substring initial=M". (Look for all surnamesbeginning with "M")

SearchAliases set to TRUE.

EIS is set to attribute Types=allAttributes,InfoTypes=attributeTypesAndValues.

Method

Obtain the EID for the base object DN using a TreeWalk. The EID of thebase object is "11".

From the Tree Table, obtain the PATH for EID=11, ie, "1.11".

Check for any aliases among entries that have a path beginning with"1.11.". There are not aliases in this case.

Obtain the AID for the attribute "surname" in the Attribute Table, ie,4.

Apply the filter and scope simultaneously. i.e. Using the Search Table,obtain a list of EID's from the target list where AID=4 and the valuebegins with "M" joined with the Tree Table who's PATH is LIKE `1.11.%`.The matching EID's are 30 and 31.

Using the Entry Table and the Attribute Table, for each matching EID:

return the OBJECTID's from the Attribute Table and the ANS.1 encoded RAWvalues from the Entry Table ie,

    ______________________________________                                        2.5.4.0,           [2.5.6.7],                                                   2.5.4.3, [Chris],                                                             2.5.4.4 [Masters]                                                             2.5.4.9 [Sales Manager]                                                       2.5.4.20 [(03) 727-9456]                                                      2.5.4.20 [(018) - 042 671]                                                    2.5.4.0 [2.5.6.7]                                                             2.5.4.3 [Alana]                                                               2.5.4.4 [Morgan]                                                              2.5.4.9 [Sales Support]                                                       2.5.4.20 [(03) 727-9454]                                                    ______________________________________                                    

5.6 Add Entry Service

An AddEntry operation is used to add a leaf entry either an object entryor an alias entry) to the Directory Information Tree.

    ______________________________________                                        X.500 definition                                                              ______________________________________                                        Argument    Description                                                       ______________________________________                                          object The Distinguished Name of the entry to be added                        entry A set of attributes to add                                              Common Arguments                                                            ______________________________________                                          Result Description                                                          ______________________________________                                          NULL NULL                                                                   ______________________________________                                    

Method

Using the DIT table, tree walk to the parent of the entry to be added(Parent EID).

Using the DIT table, check if the entry exists (check for RDN=new RDNand PARENT=Parent EID).

If the entry does not exist, allocate a new EID and add the entry.Insert into the DIT Table, the Name Table, the Tree Table, the SearchTable, the Entry Table and, if it is an alias entry, the Alias Table.

Example

Under the object with a DN of "Datacraft/Marketing" add an object withthe following attributes and values.

    ______________________________________                                        surname            [Delahunty]                                                  commonName [Mary]                                                             title [Marketing Manager]                                                     telephoneNumber [(03) 727-9523]                                             ______________________________________                                    

Obtain the EID for the base object DN using a TreeWalk. The EID of thebase object is "12".

Using the DIT Table, look for a duplicate entry, ie, PARENT=12 andRDN="MARY DELAHUNTY". No duplicate exist.

Add the following rows to the Tables shown.

    ______________________________________                                        DIT                                                                             EID       PARENT   ALIAS    RDN                                             ______________________________________                                          33 11 0 MARY DELAHUNTY                                                      ______________________________________                                        NAME                                                                            EID                 RAW                                                     ______________________________________                                          33 [Mary Delahunty]                                                         ______________________________________                                        TREE                                                                            EID                    PATH                                                 ______________________________________                                          33 1.12.21.                                                                 ______________________________________                                        SEARCH                                                                          EID     AID     VID   DISTING NORM                                          ______________________________________                                          33 0 0 0 2.5.6.7                                                              33 3 0 1 DELAHUNTY                                                            33 4 0 1 MARY                                                                 33 12   0 0 MARKETING MANAGER                                                 33 20  0 0 03 727 9523                                                      ______________________________________                                        ENTRY                                                                           EID         AID    VID      RAW                                             ______________________________________                                          33 0 0 [2.5.6.7]                                                              33 3 0 [Delahunty]                                                            33 4 0 [Mary]                                                                 33 12  0 [Marketing Manager]                                                  33 20  0 [(03) 727-9523]                                                    ______________________________________                                    

5.7 Remove Entry Service

A RemoveEntry operation is used to remove a leaf entry (either an objectentry or an alias entry) from the Directory Information Tree.

    ______________________________________                                        X.500 definition                                                              ______________________________________                                        Argument       Description                                                    ______________________________________                                          object The Distinguished Name of the entry to be                               deleted                                                                      Common Arguments                                                            ______________________________________                                          Result Description                                                          ______________________________________                                          NULL NULL                                                                   ______________________________________                                    

Method

Perform a tree walk using the DIT table. Obtain the EID of the baseobject.

If the entry exists, and it is a leaf entry, then for the conditionEID=EID of the selected object, delete from the DIT Table, the NameTable, the Tree Table, the Search Table, the Entry Table and, if it isan alias entry, the Alias Table.

Example

Delete the object with a DN of "Datacraft/Marketing/Mary Delahunty"

Method

Obtain the EID for the base object DN using a TreeWalk. The EID of thebase object is "21". Check that no entries have PARENT=21.

Delete all rows added to the DIT Table, the Name Table, the Tree Table,the Search Table and the Entry Table (refer to Add Entry example) whereEID=21.

5.8 Modify Entry Service

The ModifyEntry operation is used to perform a series of one or more ofthe following modifications to a single entry:

add a new attribute

remove an attribute

add attribute values

remove attribute values

replace attribute values

modify an alias

    ______________________________________                                        X.500 definition                                                              ______________________________________                                        Argument       Description                                                    ______________________________________                                          object The Distinguished Name of the entry to be                               modified                                                                     changes A list of modifications                                               Common Arguments                                                            ______________________________________                                          Result Description                                                          ______________________________________                                          NULL NULL                                                                   ______________________________________                                    

Method

Perform a tree walk using the DIT table. Obtain the EID of the selectedobject.

For the selected object, perform one or more of the following actions:Add Value, Delete Value, Add Attribute, Delete Attribute

The operations required for each action are as follows:

Add Value

If the attribute exists, add the value to the Entry Table and the SearchTable. Checks are: If the attribute is single valued test for anexisting value; if the attribute is multi-valued check for a duplicatevalue.

Delete Value

For the Entry Table and the Search Table, if the value exists, deleteit. A Distinguished Value cannot be deleted.

Add Attribute

If the attribute does not exist, add the Attribute Values to the EntryTable and the Search Table.

Delete Attribute

For the Entry Table and the Search Table, if the attribute exists,delete it. Delete all values with AID=attr and EID=base object. Namingattributes cannot be deleted.

Example

Modify the Entry "Datacraft/Sales/Network Products/Chris Masters" withthe following changes:

    ______________________________________                                        Delete Attribute and Value                                                                     telephoneNumber                                                                            018 - 042 671                                     Modify Attribute and Value title Sales Assistant                            ______________________________________                                    

The Search and Entry Tables reflect the changes.

    ______________________________________                                        SEARCH                                                                            EID    AID      VID  DISTING  NORM                                        ______________________________________                                          30 0 0 0 2.5.6.7                                                              30 3 0 1 CHRIS                                                                30 4 0 1 MASTERS                                                              30 12   0 0 SALES ASSISTANT                                                   30 20  0 0 03 727 9456                                                      ______________________________________                                        ENTRY                                                                           EID         AID    VID        RAW                                           ______________________________________                                          30 0 0 [2.5.6.7]                                                              30 3 0 [Chris]                                                                30 4 0 [Masters]                                                              30 12  0 [Sales Assistant]                                                    30 20  0 [(03) 727-9456]                                                    ______________________________________                                    

5.9 Modify RDN Service

The ModifyRDN operation is used to change the Relative DistinguishedName of a leaf entry (either an object entry or an alias entry) from theDirectory Information Tree.

    ______________________________________                                        Arguments   Description                                                       ______________________________________                                          object The Distinguished Name of the entry to be                               modified                                                                     newRDN The new RDN of the entry                                               deleteOldRDN flag - delete all values in the old RDN not in new                           RDN                                                               Common Arguments                                                            ______________________________________                                          Result Description                                                          ______________________________________                                          NULL NULL                                                                   ______________________________________                                    

Method

Perform a tree walk using the DIT table. Obtain the EID and Parent EIDof the base object.

Using the DIT table, check for equivalent entries and return error ifone is found. An equivalent entry has RDN=new RDN and PARENT=Parent EID.

Using the Name Table, replace the old RDN with the new RDN.

Using the DIT Table, replace the old RDN with the new RDN.

Using the Entry Table, insert the new value.

Using the Search Table, locate value=old RDN and set DISTING to 0.

Insert the new value.

If deleted OLDRDN is set to TRUE the procedure following the Tree Walkarea as follows:

Using the DIT table, check for a sibling with the same name and an EIDnot equal to the base EID

Using the Name Table, replace the old RDN with the new RDN.

Using the DIT Table, replace the old RDN with the new RDN.

Using the Entry Table, delete the old value(s) and insert the newvalue(s).

Using the Search Table, delete the old value(s) and insert the newvalue(s).

Example

Modify the RDN of "Datacraft/Sales/Network Products/Chris Masters". Thenew RDN is "Christine Masters".

deleteOLDRDN is set to FALSE.

The changes to the Tables will be as follows:

    ______________________________________                                        DIT                                                                             EID       PARENT   ALIAS    RDN                                             ______________________________________                                          21 11 0 CHRISTINE MASTERS                                                   ______________________________________                                        NAME                                                                            EID                 RAW                                                     ______________________________________                                          21 [Christine Masters]                                                      ______________________________________                                        SEARCH                                                                            EID    AID      VID  DISTING  NORM                                        ______________________________________                                          30 0 0 0 2.5.6.7                                                              30 3 0 1 CHRISTINE                                                            30 3 1 0 CHRIS                                                                30 4 0 1 MASTERS                                                              30 12   0 0 SALES ASSISTANT                                                   30 20  0 0 03 727 9456                                                      ______________________________________                                        ENTRY                                                                           EID          AID    VID        RAW                                          ______________________________________                                          30 0 0 [2.5.6.7]                                                              30 3 0 [Christine]                                                            30 3 1 [Chris]                                                                30 4 0 [Masters]                                                              30 12  0 [Sales Assistant]                                                    30 20  0 [(03) 727-9456]                                                    ______________________________________                                    

5.10 Complications

If error, limit or abandon occurs during processing of any of theservices, then the processing is discontinued and an appropriate errormessage returned.

Errors

Each X.500 service consists of 3 parts; ARGUMENT, RESULT and ERRORS. Inthe above descriptions of the services, ARGUMENT and RESULT have beenincluded in the X.500 definitions. Error conditions, however, are manyand varied and no attempt is made to describe them in this document. TheNational Institute of Standards and Technology (NIST) document "StableImplementation Agreements for Open Systems Interconnection Protocols:Version 3" provides a full coverage of errors for the X.500 standard.

Time Limit & Size Limit

Time Limit and Size Limit form part of Service Controls. They can beoptionally set to some finite limit and included in the CommonArguments.

Time Limit indicates the maximum elapsed time, in seconds, within whichthe service shall be provided. Size Limit (only applicable to List andSearch) indicates the maximum number of objects to be returned. Ifeither limit is reached an error is reported. For a limit reached on aList or a Search, the result is an arbitrary selection of theaccumulated results.

Abandon

Operations that interrogate the Directory, ie Read, Compare, List andSearch, may be abandoned using the Abandon operation if the user is nolonger interested in the results.

Aliases & Search

If an alias is encountered in a search and that alias points to aseparate branch of the directory tree, then dereferencing of the aliasrequires:

Navigation from the root entry to the referenced entry

Searching of all items subordinate to the referenced entry

In the example shown in illustrated in FIG. 5, if a WholeSubtree Searchwas performed on a base object of "Telco/Corporate/Data Services" theentries "Mervyn Purvis" and the alias "Strategic" would be searched.Strategic, however, points to a different branch of the tree whichrequires searching of the entry "Strategic" and all of its subordinates,ie., "Alan Bond", "Rex Hunt", "Wayne Carey" and "John Longmire".

5.11 Implementation Optimizations

The Logical methods include a number of optimizations that enhanceperformance. These methods are outlined below.

Caching

The Attribute table can be cached. This means that (apart from initialloading of the attributes) no SQL statements need to be issued to thedatabase when decoding or encoding the attributes. In the present X.500system attribute conversions are performed in memory. This provides asubstantial speed advantage.

Validation

Query validation is performed in memory where possible. This avoidsdatabase rollbacks which are time and system consuming. For example whenadding an entry each attribute is validated before any attempt is madeto add the entry. If an error is found then no SQL calls need to beissued.

Optimise Query Handling

As the format of most services is known, many instances of theseservices can be resolved using static SQL statements. More complexservices, such as searches with complex filters, can be resolved usingdynamic SQL. This enables arbitrarily complex searches to be performed.

Parallel Queries

Also when processing search results the present system utilizes setorientation queries of SQL to avoid `row at a time` processing. Thussearching results may be assembled in parallel in memory.

Data Storage

The tables that store raw data store the data in ASN.1 format. Thisprovides an efficient means of transfering data into or out of thedatabase.

Database Techniques

Complex services can be further improved by using the query optimizer,which provides a mechanism for reducing the time spent in resolving thequery. The use of a relational database also provides an efficient useof memory and enables large databases to be constructed without the needfor large amounts of memory being available. Many other X.500applications cache the entire database in memory to achieve performance.This method consumes large amounts of memory and is not scalable.

6. Physical Design

The physical design results from a process called physicaltransformation of the logical design. The physical design represents apreferred realization or embodiment of the logical design. FIG. 2B andthe tables below show one form of the physical design. New columns andtables are highlighted by double borders.

                                      TABLE 6                                     __________________________________________________________________________    Physical Design                                                               __________________________________________________________________________    DIT                                                                             EID PARENT RDNKEY RDN FLAGS                                                   NAME                                                                          EID RAW   FLAGS                                                             TREE                                                                            EID LEV1 LEV2 LEV3 LEV4 PATH FLAGS                                            INFO                                                                        MAXEID                                                                              FLAGS                                                                   ALIAS                                                                           EID A.sub.-- EID FLAGS                                                      SEARCH                                                                          EID AID VID NORMKEY NORM FLAGS                                                ENTRY                                                                         EID AID VID RAW  FLAGS                                                        BLOB                                                                          EID AID VID RAW FLAGS                                                         ATTR                                                                        AID  SYNTAX  DESC   OBJECTID                                                                              FLAGS                                               SENTRY                                                                      EID  AID  VID  VALUE FLAGS                                                    OCLASS                                                                        OCID DESC OBJECTID                                                                            MUSTLIST                                                                            MAYLIST                                                                             SUPERLIST                                                                           FLAGS                                       __________________________________________________________________________

The reasons for the above changes are described below.

6.1 Efficiency

INFO Table

This table holds the highest EID value that has been used in thedatabase. The inclusion of the INFO table enables the next EID to beobtained without any calculation of the maximum EID being performed bythe database. This provides improved efficiency in adding entries to thedata base. More importantly the including of the INFO table removescontention problems which may occur when multiple DSA's are addingentries at the same time.

Shadow Keys

Three tables have had shadow keys added. These are:

a) The NORMKEY column in the SEARCH table.

b) The RDNKEY column in the DIT table.

c) The LEV1, LEV2, LEV3 and LEV4 columns in the TREE table.

Each of these shadow key columns is a shortened version of a largercolumn. They have been added to shorten the indexes on each table. Thisgives improved performance for any queries that use the indexes and italso improves disk space usage as small indexes take up less space thanlarge indexes.

The shadow keys in the PATH table utilise the structured nature of thePATH. By being a composite key then exact matching can be used in theSQL instead of the "LIKE" operator.

e.g. WHERE LEV1=1 and LEV2=10 AND . . . instead of WHERE PATH LIKE`1.10.%`.

If each of the LEV columns has their own index, then a sub-tree searchneeds to only use the base object. e.g. LEV2=10, since all objects underentry 10 will have LEV2=10.

SENTRY Table

Some types of attribute values do not need to be normalised e.g.integer, boolean, date. Instead of storing them twice (SEARCH.NORM andENTRY.RAW) they can be stored just once in a hybrid table called theSENTRY table. This reduces table sizes and increases storage efficiencyat the cost of having to search two tables and retrieve from two tables.

OCLASS Table

Most attributes have a wide variation in their values e.g. surnamescould range from AALDERS to ZYLA with a great many different values inbetween. However, Object Classes (whose values are ObjectIdentifiers orOIDs) have very few values e.g. in an organisation of 10,000 people, theonly object classes in the directory may be for organisation,organisationlUnit and organisationalPerson (of which many may be thelatter). The OCLASS table gives a numeric descriptor to an object classcalled an OCID. The OCID can then be stored in the SENTRY table and amapping done whenever an Object Class is searched or retrieved. Theother LIST columns store standard object class configurationinformation--namely the must and may contain attributes and theinherited superclasses.

6.2 Portability

BLOB Table

This table has been included to hold "Binary Large Objects". The maximumsize of a one row entry in the ENTRY table is limited by the length ofthe RAW field. This means that entries must be fragmented. Fragmentedentries will occupy more than one row and so a VFRAG field must be usedto denote the fragment of the entry that is being stored in a particularrow.

There are two options for storing very large values:

a) Add a "fragment flag" to the ENTRY table and store the entry infragments over a number of lines; or

b) Add a BLOB table to store the entry and add a "BLOB flag" to theENTRY table to indicate that this value is stored in the BLOB.

The second option has a number of advantages. Firstly, the inclusion ofa BLOB table prevents the ENTRY table from becoming excessively large.Generally most entries will be less than a few hundred characters inlength, so the length of the RAW field in the ENTRY table canaccordingly be reduced to cater for those entries and the RAW field inthe BLOB table can be increased to a value approaching the maximumrecord size. This will make storage more efficient, i.e. reduce theamount of unused bytes in each column of each table and reduce thenumber of fragments needed for each entry in the BLOB table, it alsomeans that each value will have only one entry in the ENTRY table andthat the ENTRY and SEARCH table maintain their one-to-one correlation.Secondly the use of a BLOB table enables the application to make use ofany database support for Binary Large Objects. (e.g. 64K BinaryColumns).

6.3 Functional Extensibility

FLAGS Columns

FLAGS column(s) are preferred to be added. These column(s) have beenadded to provide extensibility to the design. Specific values can beadded to the flags as new functionality is required, without changingthe table structure.

Note:

a) In the SEARCH table, the DISTING field may be absorbed into the FLAGSfield.

b) In the DIT table, the ALIAS field may be absorbed into the FLAGSfield.

The FLAGS column(s) may also provide a "summary" function for each ofthe tables. This means that the nature of an entry can be determined tosome extent by checking the value of the FLAGS field. For example, aflag can be set, in the DIT table, when an entry is a leaf. Checkingthis flag is much simpler than checking for children of the entry.

The FLAGS column can also be used to store security information, whetheran alias points inside its parents sub-tree, whether a value is a BLOB,etc.

7. Example Implementation

The following provides an example of system performance andcapabilities. It is to be understood that the present inventions shouldnot be limited to the following disclosure.

7.1 Overall System Benefits

The present invention is considered to provide enhanced performance overprior art implementations. Performance can be appraised in many ways,including:

aliases;

size (use of relational theory);

complexity (use of query optimizer and search method(s));

extensibility (use of meta-data); and

substantially without degrading efficiency (use of disk based mode) and

reliability (use of RDBMS).

The present invention is considered unique in its ability to claimperformance improvement in all areas noted above.

7.2 Test Results

Performance testing of the present invention has been carried out, withthe objectives of:

Proving that an SQL based X.500 application can perform at subsecondspeeds, dispelling a widely held myth in the marketplace that it isimpossible to implement and X.500 DSA application as an integrated RDBMSapplication and achieve efficiency and performance.

Proving that the design of an SQL based X.500 application can outperformexisting memory resident style X.500 designs, especially for databasesin excess of 100K entries, a typical limit of current designs.

Providing a structured suite of test that can demonstrate the aboveperformance on demand for a wide variety of services and data basesizes.

Test results reveal the following Table 7A:

                                      TABLE 7A                                    __________________________________________________________________________    Service                    Database Size (number of entries)                  Operation                                                                           Qualifier  Detail    1K 10K                                                                              20K                                                                              50K                                                                              100K                                                                             200K                                __________________________________________________________________________    BIND  anonymous            0.00                                                                             0.00                                                                             0.00                                                                             0.00                                                                             0.00                                                                             0.00                                  LIST level 1 4 items 0.05 0.05 0.05 0.05 0.05 0.05                             level 3 4 items 0.06 0.06 0.06 0.06 0.06 0.06                                 level 4 1 00 items 0.22 0.23 0.23 0.24 0.23 0.24                             READ level 4 1 item, all info 0.07 0.07 0.07 0.07 0.07 0.08                    level 4 (via alias) 1 item, all info 0.07 0.07 0.07 0.07 0.07 0.07                                                    SEARCH 1 level, equality 100                                                 entries, 1 item 0.12 0.12 0.12                                                0.12 0.13 0.13                         1 level, initial 100 entries, i item 0.13 0.14 0.15 0.15 0.15 0.14                                                     1 level, any 100 entries, 1                                                 item 0.30 0.35 0.33 0.32 0.36                                                 0.29                                   1 level, final 100 entries, 1 item 0.24 0.35 0.31 0.30 0.35 0.28                                                       subtree, equality 1K, 1 item,                                               level 1 0.11 0.11 0.11 0.11                                                   0.11 0.11                               10K, 1 item, level 1 xxx xxx 0.12 0.12 0.12 0.12                              20K, 1 item, level 1 xxx xxx xxx 0.12 0.13 0.12                               50K, 1 item, level 1 xxx xxx xxx xxx 0.13 0.13                                100K, 1 item, level 1 xxx xxx xxx xxx xxx 0.12                               subtree, initial 1K, 1 item, level 1 0.13 0.12 0.12 0.12 0.12 0.11                                                      10K, 1 item, level 1 xxx xxx                                               0.11 0.12 0.12 0.12                     20K, 1 item, level 1 xxx xxx xxx 0.13 0.12 0.12                               50K, 1 item, level 1 xxx xxx xxx xxx 0.13 0.12                                100K, 1 item, level 1 xxx xxx xxx xxx xxx 0.11                               full, complex OR all entries, 1 item 0.09 0.09 0.09 0.09 0.09 0.09                                                     full, complex AND all                                                       entries, 1 item 0.11 0.11 0.11                                                0.11 0.11 0.11                         full, complex OR/AND all entries, 1 item 0.26 0.28 0.29 0.28 0.29 0.26        full, complex AND/OR all entries, 1 item 0.12 0.12 0.13 0.14 0.13 0.12        full, complex AND/AND all entries, 1 item 0.16 0.15 0.16 0.17 0.18                                                   0.18                                   full, complex all entries, 1 item 0.18 0.18 0.18 0.19 0.20 0.26                                                        AND/AND/AND                          full, equality all entries, 1 item 0.08 0.08 0.08 0.08 0.08 0.08                                                       full, no filter, all-info all                                               entries, 10 items 0.30 0.74                                                   0.43 0.59 0.49 0.67                    full, no filter, all-info all entries, 100 items 1.36 1.84 1.50 1.79                                                 1.82 1.86                              full, initial all entries, 1 item 0.08 0.08 0.08 0.08 0.08 0.08                                                       ADD level 5 100 sisters 0.22                                                 0.19 0.22 0.20 0.19 0.19                                                       MODIFY level 5 100 sisters                                                   0.09 0.11 0.11 0.11 0.11 0.11                                                  RENAME level 5 100 sisters                                                   0.15 0.16 0.15 0.16 0.16 0.15                                                  DELETE level 5 100 sisters                                                   0.17 0.16 0.17 0.17 0.17 0.19                                                  UNBIND   0.00 0.00 0.00 0.00                                                 0.00 0.00                           __________________________________________________________________________     Notes:                                                                        1. All searches and reads return all info                                     2. All tests were performed under the following environment:                  * Sun SparcStation 5 with 32Mb of memory (entry level UNIX machine)           * Ingres 6.4/04 configured for 32 users (standard Ingres installation)        * DSA prototype V2.1.2                                                        * Timings measured at DSA console (ie does not include network overheads)     All numbers are in units of seconds and "K" means 1,000's.               

7.3 Test Conclusions

A set of directories was constructed ranging from 1K to 200K entrieswith varying depth and width of the hierarchy, and a corresponding testplan was produced. The tests were performed a number of times to ensureconsistency. The following conclusions can be drawn from these results:

1. The effects of navigation, in test, were negligible.

2. Reading an object via an alias, in test, showed no appreciabledecrease in performance and in some cases reading an object via an aliaswas in fact faster than reading the object directly. This is due to thereduced navigation required when an alias points "down" to an objectthat is deeper in the tree structure than the alias entry.

3. Search results were "flat" over different sized subtrees in differentsized directories for both exact and initial string searches.

4. Initial and exact full tree searches, in test, were slightly quickerthan their respective subtree searches, even though the number ofentries searched was greater. This is due to the fact that the full treesearches are able to use more efficient SQL (no table joins arerequired).

5. All services were, in test, performed in under one second, except forsearches returning large amounts of data. However the average time ofretrieval per entry drops as the number of entries retrieved increases(e.g. for 10 entries retrieval time is approximately 50 milliseconds perentry, the 100 entries this drops to approximately 20 milliseconds perentry).

6. All complex searches, in test, were performed in under one second.However, there may be some obscure searches (e.g. containingcombinations of NOT) which may not perform as well.

Because this is a disk based system (rather than a memory based system)performance is essentially only dependent on the number of entriesactually returned. It is relatively independent of the searchcomplexity, the depth of the hierarchy, the number of attributes perentry or the types of attributes used in the query. In a "live"application of the system it may be possible to improve on the achievedtest results by tuning the caching parameters, and by having a greaterdiversity of attributes.

I claim:
 1. Apparatus adapted to implement X.500 services to arelational database comprising:a storage arrangement operative toconcurrently store information in the database in both a protocolencoded form and a syntax-normalized form.
 2. Apparatus as claimed inclaim 1, where the relational database is a RDBMS that uses SQL. 3.Apparatus as claimed in claims 1 or 2, wherein the protocol encoded formis ASN.1.
 4. A data base application comprising:means for implementingX.500 services, said means having a function operative with meta data,for storing a plurality of different types of data for plurality ofdifferent objects in the same table.
 5. A database application asclaimed in claim 4, wherein the meta-data is stored in a single propertytable.
 6. A database application as claimed in claim 4, wherein themeta-data is stored relatively independent of data type.
 7. A databaseapplication as claimed in claim 4, wherein the meta-data is storedrelatively independent of language alphabet.
 8. A database applicationas claimed in claim 4, wherein the meta-data is stored such that itexists concurrently in both a protocol encoded form and asyntax-normalized form.
 9. An application as claimed in any one ofclaims 4, 5, 6, 7 or 8, where the X.500 services are invoked using atleast one of an X.500 and LDAP protocol.
 10. A method as set forth inclaim 4, wherein said data types are treated as generic.
 11. Arelational database comprising:at least one attribute table, at leastone object table containing a plurality of objects, and at least onehierarchy table containing information defining interrelationshipsbetween and among said plurality of objects.
 12. A database as claimedin claim 11, where the X.500 services are invoked using at least one ofan X.500 and LDAP protocol.
 13. A method of performing X.500 servicesusing a database, the method including the steps of:a) converting anincoming X.500 services request into at least one query on tables withsyntax-normalized data, and b) basing outgoing X.500 services responseson at least one query on tables with protocol encoded data. 14.Apparatus adapted to perform the method as claimed in claim
 13. 15. Anapparatus as claimed in claim 14, wherein tables containingsyntax-normalized data are clustered around an attribute identifier. 16.An apparatus as claimed in claim 14 or 15, wherein tables containingprotocol encoded data are clustered around an entry identifier.
 17. Anapparatus as claimed in any one of claims 1, 2, 3, 14, 15 or 16, wherethe X.500 services are invoked using an X.500 and/or LDAP protocol. 18.A method of searching an area in a database using search services, themethod comprising the step of:applying a filter limited to a selectedarea of a directory information tree for said database.
 19. A method asclaimed in claim 18, where the step of applying a filter is applied onlyto syntax-normalized meta data.
 20. A method of searching an area in adatabase which includes aliases, the method comprising the stepsof:expanding the search area by resolving aliases until a set of searchareas with no unresolved aliases is found; and applying a filter limitedto a selected area of a directory information tree for said database tosaid set of search areas.
 21. A method as claimed in claim 18, 19 or 20,wherein the database uses X.500.
 22. A method as claimed in claim 18, 19or 20, wherein evaluating the filter and the scope is performed bysingle pass resolution.
 23. A method of implementing X.500 services to arelational database, the method comprising:translating each variation ofeach X.500 service into a fixed set of queries which is substantiallyindependent of data type.
 24. A method as claimed in claim 23, where thedatabase is a relational database with SQL.
 25. A method as claimed inclaim 24, where the database has 250,000 or more entries.
 26. A methodof implementing X.500 services on a relational database, the methodcomprising the step of applying a process of functional decomposition toa property table, said property table comprising a hierarchy of objectswith attributes.
 27. A method of implementing X.500 services, as claimedin claim 26, further comprising the step of applying a process ofservice decomposition.
 28. A method of implementing X.500 services, asclaimed in claim 27, further comprising the step of applying a processof physical transformation.
 29. A method of implementing X.500 services,is claimed in claim 26, 27 or 28, wherein at least one of the steps ofapplying a process of functional decomposition, service decomposition,and physical transformation results in data being stored concurrently ina protocol encoded form and a syntax-normalized form.
 30. A method asclaimed in any one of claims 13, 14, 21, 23, 24, 25, 26, 27, 28 and 29,where the X.500 services are invoked using at least one of an X.500 andLDAP protocol.
 31. A method as set forth in claim 28, wherein saidprocess of physical transformation results in a third set of tableswhich separate out at least components of said attribute table.
 32. Amethod as set forth in claim 31, wherein the access to components in thethird set of tables provides at least one of efficiency, portability andfunctional extensibility.
 33. A method as set forth in claim 27, whereinsaid process of service decomposition results in a second set of tableswhich separate out at least components of said hierarchy table andobject table.
 34. A method as set forth in claim 33, wherein thehierarchy components in said second set of tables comprise at least oneof a DIT, NAME, TREE and ALIAS table.
 35. A method as set forth in claim33 wherein the object components in said second set of tables compriseat least one of a SEARCH and ENTRY table.
 36. A method as set forth inclaim 26, wherein said process of functional decomposition results in afirst set of tables which separate out said hierarchy, object andattribute into separate tables.
 37. A method of adding a new X.500 datatype without changing table structures in a database, which comprises atleast an attribute table, the method including the step of:adding a newrow with a unique identifier to an attribute table.
 38. A method ofadding a value of an X.500 object to a database, the method comprisingthe step of:using a unique identifier from an attribute table as aforeign key to other tables.
 39. Apparatus adapted to perform the methodas claimed in any one of claims 13 to
 38. 40. A device or systemincorporating the apparatus and/or method of any one of claims 1 to 39.